MA5600T&MA5603T V800R010C00 Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module V800R010C00
Feature Description
Issue Date 01 2011-10-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China http://www.huawei.com support@huawei.com
Website: Email:
Issue 01 (2011-10-30)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description
About This Document
About This Document

Intended Audience
This document describes the key features (including ADSL,VDSL2, SHDSL, GPON, VoIP, ISDN, FoIP, MoIP, P2P Access, Layer 2 Protocol Handling, Layer 3 Features, VLAN, ACL, QoS, Multicast and security features) of the SmartAX MA5600T/MA5603T (hereinafter referred to as the MA5600T/MA5603T) in detail from the following aspects: l l l l l l Definition Purpose Specification Availability Principle Reference
After reading this document, you can learn about the definitions and purposes of the various features of the MA5600T/MA5603T, and also the support of these features by the MA5600T/ MA5603T and the references on these features. In this way, you can know the feature list of the MA5600T/MA5603T and understand the implementation of these features on the MA5600T/ MA5603T. This document is intended for: l l l l Network planning engineers System maintenance engineers Configuration engineers NM administrators
Symbol Conventions
The following symbols may be found in this document. They are defined as follows Symbol Description Indicates a hazard with a high level of risk which, if not avoided, will result in death or serious injury.
Issue 01 (2011-10-30)
ii
About This Document
Symbol
Description Indicates a hazard with a medium or low level of risk which, if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation that, if not avoided, could cause equipment damage, data loss, and performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save your time. Provides additional information to emphasize or supplement important points of the main text.
Update History
Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues.
Updates in Issue 01 (2011-10-30)

This is the first release of V800R010C00. Compared with issue 01 (2011-07-15) of V800R009C00, this issue has the following changes: The following information is added: l l l l l l l 12 IPv6 20.8 ONT DHCP Simulation 14.8 Type C Protection of GPON Lines 7 MPLS Updated the specifications of 4 VDSL2 Access, 1 GPON, and 13 Multicast. Modified the content of 9.3 1:1 VMAC, 21.3 Ethernet CFM OAM, and 9.8 Bridging. Modified the structure and the content of 17.9 Service Overload Control.
The following information is modified:
Issue 01 (2011-10-30)
iii
Contents
Contents
About This Document.....................................................................................................................ii 1 GPON...............................................................................................................................................1
1.1 Introduction........................................................................................................................................................2 1.2 Specifications......................................................................................................................................................2 1.3 Reference Standards and Protocols....................................................................................................................4 1.4 Availability.........................................................................................................................................................4 1.5 Overview of the GPON System..........................................................................................................................5 1.6 GPON Principle..................................................................................................................................................7 1.7 Key GPON Technologies.................................................................................................................................13 1.8 GPON Terminal Authentication and Management..........................................................................................16 1.9 Continuous-Mode ONU Detection...................................................................................................................25 1.10 GPON Network Applications.........................................................................................................................28 1.11 Glossary, Acronyms, and Abbreviations........................................................................................................29
2 P2P Optical Access......................................................................................................................30

2.1 P2P FE Optical Access.....................................................................................................................................31 2.1.1 Introduction.............................................................................................................................................31 2.1.2 Specifications...........................................................................................................................................31 2.1.3 Reference Standards and Protocols.........................................................................................................31 2.1.4 Availability..............................................................................................................................................31 2.1.5 Principle...................................................................................................................................................32 2.2 GE P2P Optical Access....................................................................................................................................33 2.2.1 Introduction.............................................................................................................................................33 2.2.2 Specifications...........................................................................................................................................36 2.2.3 Reference Standards and Protocols.........................................................................................................40 2.2.4 Availability..............................................................................................................................................40 2.2.5 Network Applications..............................................................................................................................41
3 ADSL2+ Access............................................................................................................................44
3.1 Introduction......................................................................................................................................................45 3.2 Specifications....................................................................................................................................................45 3.3 Reference..........................................................................................................................................................46 3.4 Availability.......................................................................................................................................................46 3.5 Principle............................................................................................................................................................46 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. iv
Contents
3.6 Glossary, Acronyms, and Abbreviations..........................................................................................................53
4 VDSL2 Access...............................................................................................................................55
4.1 Introduction......................................................................................................................................................56 4.2 Specifications....................................................................................................................................................56 4.3 Reference Standards and Protocols..................................................................................................................57 4.4 Availability.......................................................................................................................................................57 4.5 VDSL2 Architecture.........................................................................................................................................58 4.6 Features of the VDSL2 System........................................................................................................................60 4.7 Support for Multiple Spectrum Profiles...........................................................................................................61 4.8 Flexible PSD Control Methods.........................................................................................................................63 4.9 Improvement of Line Performance...................................................................................................................66 4.10 VDSL2 Network Applications.......................................................................................................................73
5 SHDSL Access..............................................................................................................................75
5.1 ATM SHDSL Access.......................................................................................................................................76 5.1.1 Introduction.............................................................................................................................................76 5.1.2 Specifications...........................................................................................................................................76 5.1.3 Availability..............................................................................................................................................77 5.1.4 Reference.................................................................................................................................................77 5.1.5 Principle...................................................................................................................................................77 5.1.6 Acronyms and Abbreviations..................................................................................................................79 5.2 EFM SHDSL Access........................................................................................................................................79 5.2.1 Introduction.............................................................................................................................................79 5.2.2 Specifications...........................................................................................................................................80 5.2.3 Availability..............................................................................................................................................80 5.2.4 Reference.................................................................................................................................................81 5.2.5 Principle...................................................................................................................................................81 5.2.6 Glossary, Acronyms, and Abbreviations.................................................................................................83 5.3 TDM SHDSL Feature.......................................................................................................................................83 5.3.1 Introduction.............................................................................................................................................83 5.3.2 Specifications...........................................................................................................................................84 5.3.3 Reference Standards and Protocols.........................................................................................................85 5.3.4 Availability..............................................................................................................................................85 5.3.5 Principle...................................................................................................................................................86 5.3.6 Narrowband Data Private Line Service Applications..............................................................................87 5.3.7 PRA Carrying Applications.....................................................................................................................89 5.3.8 Glossary, Acronyms, and Abbreviations.................................................................................................90
6 ATM Access..................................................................................................................................92
6.1 Introduction......................................................................................................................................................93 6.2 Specifications....................................................................................................................................................94 6.3 Reference Standards and Protocols..................................................................................................................94 6.4 Availability.......................................................................................................................................................94 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. v
Contents
6.5 Principle............................................................................................................................................................95
7 MPLS..............................................................................................................................................97
7.1 Overview..........................................................................................................................................................98 7.2 Reference Standards and Protocols..................................................................................................................98 7.3 Availability.....................................................................................................................................................100 7.4 MPLS..............................................................................................................................................................100 7.4.1 Introduction...........................................................................................................................................101 7.4.2 Specifications.........................................................................................................................................101 7.4.3 Principle.................................................................................................................................................102 7.5 MPLS RSVP-TE.............................................................................................................................................108 7.5.1 Introduction...........................................................................................................................................108 7.5.2 Specifications.........................................................................................................................................109 7.5.3 Principle.................................................................................................................................................109 7.6 MPLS OAM...................................................................................................................................................111 7.6.1 Introduction...........................................................................................................................................111 7.6.2 Specifications.........................................................................................................................................112 7.6.3 Principle.................................................................................................................................................112 7.7 Glossary, Acronyms, and Abbreviations........................................................................................................114
8 Layer 2 VPN................................................................................................................................120
8.1 PWE3..............................................................................................................................................................121 8.1.1 Introduction...........................................................................................................................................121 8.1.2 Specifications.........................................................................................................................................121 8.1.3 Reference Standards and Protocols.......................................................................................................123 8.1.4 Availability............................................................................................................................................123 8.1.5 Enhanced Feature..................................................................................................................................123 8.1.6 Principle.................................................................................................................................................124 8.1.6.1 Basic Principle of PWE3..............................................................................................................124 8.1.6.2 Principle of TDM PWE3..............................................................................................................130 8.1.6.3 ATM PWE3 Principle..................................................................................................................135 8.1.6.4 Principle of ETH PWE3...............................................................................................................141 8.1.6.5 Traffic Label Principle..................................................................................................................143 8.1.6.6 PW Redundancy...........................................................................................................................144 8.1.6.7 PW OAM (VCCV).......................................................................................................................145 8.1.7 Network Applications............................................................................................................................148 8.1.8 Glossary, Acronyms, and Abbreviations...............................................................................................150 8.2 Native TDM....................................................................................................................................................152 8.2.1 Introduction...........................................................................................................................................152 8.2.2 Specifications.........................................................................................................................................152 8.2.3 Reference...............................................................................................................................................152 8.2.4 Availability............................................................................................................................................153 8.2.5 Principle.................................................................................................................................................153 8.3 Glossary, Acronyms, and Abbreviations........................................................................................................155 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. vi
Contents
9 Layer 2 Protocol Handling.......................................................................................................157

9.1 Overview........................................................................................................................................................158 9.2 MAC Address Management...........................................................................................................................158 9.2.1 Introduction...........................................................................................................................................158 9.2.2 Specifications.........................................................................................................................................159 9.2.3 Availability............................................................................................................................................160 9.2.4 Principle.................................................................................................................................................160 9.3 1:1 VMAC......................................................................................................................................................161 9.3.1 Introduction...........................................................................................................................................161 9.3.2 Specifications.........................................................................................................................................162 9.3.3 Availability............................................................................................................................................162 9.3.4 Feature Enhancement............................................................................................................................163 9.3.5 Principle.................................................................................................................................................163 9.3.6 Glossary, Acronyms, and Abbreviations...............................................................................................167 9.4 N:1 VMAC.....................................................................................................................................................168 9.4.1 Introduction...........................................................................................................................................168 9.4.2 Specifications.........................................................................................................................................169 9.4.3 Availability............................................................................................................................................169 9.4.4 Principle.................................................................................................................................................170 9.5 VLAN Management.......................................................................................................................................172 9.5.1 VLAN Overview...................................................................................................................................172 9.5.2 Specifications.........................................................................................................................................173 9.5.3 Reference Standards and Protocols.......................................................................................................173 9.5.4 Availability............................................................................................................................................173 9.5.5 Types of VLAN.....................................................................................................................................174 9.5.6 VLAN Attribute.....................................................................................................................................176 9.5.7 VLAN Processing..................................................................................................................................178 9.5.8 VLAN Aggregation...............................................................................................................................179 9.5.9 Special Applications of VLANs............................................................................................................180 9.6 VLAN Switching Policy.................................................................................................................................180 9.6.1 Introduction...........................................................................................................................................180 9.6.2 Specifications.........................................................................................................................................181 9.6.3 Availability............................................................................................................................................181 9.6.4 VLAN Tag Transforming of Traffic Streams........................................................................................181 9.7 Forwarding Policy..........................................................................................................................................192 9.7.1 Introduction...........................................................................................................................................192 9.7.2 Specifications.........................................................................................................................................193 9.7.3 Availability............................................................................................................................................193 9.7.4 Principle.................................................................................................................................................194 9.8 Bridging..........................................................................................................................................................195 9.8.1 Introduction...........................................................................................................................................195 9.8.2 Specifications.........................................................................................................................................196 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. vii
Contents
9.8.3 Reference Standards and Protocols.......................................................................................................196 9.8.4 Availability............................................................................................................................................196 9.8.5 Principle.................................................................................................................................................197 9.9 Glossary, Acronyms, and Abbreviations........................................................................................................200
10 QoS.............................................................................................................................................202
10.1 QoS Processing.............................................................................................................................................203 10.2 Traffic Classification....................................................................................................................................204 10.2.1 Overview.............................................................................................................................................204 10.2.2 Specifications.......................................................................................................................................205 10.2.3 Availability..........................................................................................................................................207 10.2.4 Principle...............................................................................................................................................207 10.3 Priority Processing........................................................................................................................................208 10.3.1 Overview.............................................................................................................................................208 10.3.2 Specifications.......................................................................................................................................208 10.3.3 Availability..........................................................................................................................................209 10.3.4 Principle...............................................................................................................................................210 10.4 Traffic Policing.............................................................................................................................................212 10.4.1 Overview.............................................................................................................................................212 10.4.2 Specifications.......................................................................................................................................213 10.4.3 Availability..........................................................................................................................................213 10.4.4 Traffic Policing Principle....................................................................................................................213 10.4.5 DBA Principle.....................................................................................................................................216 10.5 ACL Policy...................................................................................................................................................217 10.5.1 Introduction.........................................................................................................................................218 10.5.2 Specifications.......................................................................................................................................218 10.5.3 Availability..........................................................................................................................................219 10.5.4 Principle...............................................................................................................................................220 10.6 Congestion Avoidance and Management.....................................................................................................222 10.6.1 Overview.............................................................................................................................................222 10.6.2 Specifications.......................................................................................................................................222 10.6.3 Availability..........................................................................................................................................222 10.6.4 Congestion Avoidance Principle.........................................................................................................223 10.6.5 Congestion Management Principle......................................................................................................224 10.7 HQoS............................................................................................................................................................227 10.7.1 Overview.............................................................................................................................................227 10.7.2 Specifications.......................................................................................................................................228 10.7.3 Reference Standards and Protocols.....................................................................................................228 10.7.4 Availability..........................................................................................................................................228 10.7.5 Principle of Priority-based HQoS........................................................................................................228 10.7.6 Principle of HQoS Based on CAR Group...........................................................................................230 10.8 QoS Network Application............................................................................................................................235 10.8.1 Typical QoS Application in an FTTH/P2P Network...........................................................................235 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. viii
Contents
10.8.2 Typical QoS Application in an FTTB/FTTC Network.......................................................................237 10.9 Glossary, Acronyms, and Abbreviations......................................................................................................238
11 Layer 3 Features........................................................................................................................241
11.1 ARP..............................................................................................................................................................242 11.1.1 Introduction.........................................................................................................................................242 11.1.2 Specifications.......................................................................................................................................242 11.1.3 Reference Standards and Protocols.....................................................................................................242 11.1.4 Availability..........................................................................................................................................242 11.1.5 Principle...............................................................................................................................................243 11.2 ARP Proxy....................................................................................................................................................244 11.2.1 Introduction.........................................................................................................................................244 11.2.2 Specifications.......................................................................................................................................244 11.2.3 Reference Standards and Protocols.....................................................................................................244 11.2.4 Availability..........................................................................................................................................244 11.2.5 Principle...............................................................................................................................................245 11.3 DHCP Relay.................................................................................................................................................246 11.3.1 Introduction.........................................................................................................................................246 11.3.2 Specifications.......................................................................................................................................246 11.3.3 Reference Standards and Protocols.....................................................................................................247 11.3.4 Availability..........................................................................................................................................247 11.3.5 DHCPv4 Layer 2 Relay Principle.......................................................................................................248 11.3.6 DHCPv4 Layer 3 Relay Principle.......................................................................................................248 11.3.7 Networking Application......................................................................................................................249 11.4 DHCP Proxy.................................................................................................................................................250 11.4.1 Introduction.........................................................................................................................................250 11.4.2 Specifications.......................................................................................................................................251 11.4.3 Reference Standards and Protocols.....................................................................................................251 11.4.4 Availability..........................................................................................................................................251 11.4.5 Principle...............................................................................................................................................251 11.5 IP-aware Bridge............................................................................................................................................255 11.5.1 Introduction.........................................................................................................................................255 11.5.2 Specifications.......................................................................................................................................255 11.5.3 Availability..........................................................................................................................................255 11.5.4 Principle...............................................................................................................................................256 11.6 VRRP Snooping...........................................................................................................................................260 11.6.1 Introduction.........................................................................................................................................260 11.6.2 Specifications.......................................................................................................................................261 11.6.3 Reference Standards and Protocols.....................................................................................................261 11.6.4 Availability..........................................................................................................................................261 11.6.5 Principle...............................................................................................................................................262 11.6.6 Glossary, Acronyms, and Abbreviations.............................................................................................264 11.7 Routing.........................................................................................................................................................265 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. ix
Contents
11.7.1 Introduction.........................................................................................................................................265 11.7.2 Reference Standards and Protocols.....................................................................................................265 11.7.3 Availability..........................................................................................................................................265 11.7.4 Specifications.......................................................................................................................................266 11.7.5 Principle...............................................................................................................................................266 11.7.6 Static Route..........................................................................................................................................271 11.7.6.1 Introduction to Static Routes......................................................................................................271 11.7.6.2 Specifications..............................................................................................................................271 11.7.6.3 References..................................................................................................................................271 11.7.6.4 Components of Static Routes.....................................................................................................271 11.7.6.5 Applications of Static Routes.....................................................................................................272 11.7.6.6 BFD for Static Routes.................................................................................................................274 11.7.6.7 Terms and Abbreviations............................................................................................................274 11.7.7 RIP.......................................................................................................................................................275 11.7.7.1 Introduction to RIP.....................................................................................................................275 11.7.7.2 Specifications..............................................................................................................................275 11.7.7.3 References..................................................................................................................................275 11.7.7.4 RIP-1...........................................................................................................................................276 11.7.7.5 RIP-2...........................................................................................................................................276 11.7.7.6 Timer..........................................................................................................................................277 11.7.7.7 Split Horizon...............................................................................................................................277 11.7.7.8 Poison Reverse...........................................................................................................................278 11.7.7.9 Triggered Update........................................................................................................................278 11.7.7.10 Route Aggregation....................................................................................................................279 11.7.7.11 Multi-process and Multi-instance.............................................................................................280 11.7.7.12 Hot Backup...............................................................................................................................280 11.7.7.13 Terms and Abbreviations..........................................................................................................280 11.7.8 IS-IS.....................................................................................................................................................281 11.7.8.1 Introduction to IS-IS...................................................................................................................281 11.7.8.2 Specifications..............................................................................................................................281 11.7.8.3 References..................................................................................................................................281 11.7.8.4 Basic Concepts of IS-IS..............................................................................................................283 11.7.8.5 IS-IS Multi-instance and Multi-process.....................................................................................300 11.7.8.6 IS-IS Route Leaking...................................................................................................................300 11.7.8.7 IS-IS Fast Convergence..............................................................................................................302 11.7.8.8 Priority-based IS-IS Convergence..............................................................................................303 11.7.8.9 IS-IS LSP Fragment Extension...................................................................................................303 11.7.8.10 IS-IS Administrative Tag..........................................................................................................306 11.7.8.11 Dynamic Hostname Exchange Mechanism..............................................................................307 11.7.8.12 IS-IS HA...................................................................................................................................308 11.7.8.13 IS-IS 3-Way Handshake...........................................................................................................309 11.7.8.14 IS-IS GR...................................................................................................................................309 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. x
Contents
11.7.8.15 IS-IS Wide Metric....................................................................................................................317 11.7.8.16 BFD for IS-IS...........................................................................................................................318 11.7.8.17 IS-IS Authentication.................................................................................................................321 11.7.8.18 Terms and Abbreviations..........................................................................................................323 11.7.9 OSPF....................................................................................................................................................325 11.7.9.1 Introduction to OSPF..................................................................................................................325 11.7.9.2 Specifications..............................................................................................................................326 11.7.9.3 References..................................................................................................................................326 11.7.9.4 Fundamentals of OSPF...............................................................................................................327 11.7.9.5 OSPF GR....................................................................................................................................338 11.7.9.6 OSPF NSSA...............................................................................................................................341 11.7.9.7 BFD for OSPF............................................................................................................................342 11.7.9.8 OSPF Smart-discover.................................................................................................................344 11.7.9.9 OSPF-BGP Association..............................................................................................................344 11.7.9.10 OSPF Database Overflow.........................................................................................................345 11.7.9.11 OSPF Fast Convergence...........................................................................................................346 11.7.9.12 OSPF Mesh-Group...................................................................................................................348 11.7.9.13 Priority-based OSPF Convergence...........................................................................................350 11.7.9.14 Terms and Abbreviations..........................................................................................................350 11.7.10 BGP...................................................................................................................................................350 11.7.10.1 Introduction to BGP..................................................................................................................350 11.7.10.2 Specifications............................................................................................................................352 11.7.10.3 References................................................................................................................................352 11.7.10.4 Basic Principle of BGP.............................................................................................................353 11.7.10.5 Route Import.............................................................................................................................360 11.7.10.6 Route Aggregation....................................................................................................................360 11.7.10.7 Route Dampening.....................................................................................................................360 11.7.10.8 Community Attribute................................................................................................................361 11.7.10.9 BGP Confederation...................................................................................................................363 11.7.10.10 BGP GR..................................................................................................................................364 11.7.10.11 BGP Tracking.........................................................................................................................365 11.7.10.12 BGP Dynamic Update Peer-Groups.......................................................................................366 11.7.10.13 4-Byte AS Number.................................................................................................................368 11.7.10.14 Terms and Abbreviations........................................................................................................371 11.7.11 VRF...................................................................................................................................................372 11.7.11.1 Introduction..............................................................................................................................372 11.7.11.2 Specifications............................................................................................................................373 11.7.11.3 Principle....................................................................................................................................373 11.7.12 Routing Policies.................................................................................................................................374 11.7.12.1 Introduction to Routing Policies...............................................................................................374 11.7.12.2 References................................................................................................................................375 11.7.12.3 Basic Principle of Routing Policies..........................................................................................375 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xi
Contents
11.7.12.4 Application Environment.........................................................................................................376 11.7.12.5 BGP to IGP...............................................................................................................................377 11.7.12.6 Terms and Abbreviations..........................................................................................................378 11.7.13 ECMP................................................................................................................................................378 11.7.13.1 Introduction..............................................................................................................................378 11.7.13.2 Specifications............................................................................................................................378 11.7.13.3 Principle....................................................................................................................................379
12 IPv6.............................................................................................................................................380
12.1 Introduction to IPv6......................................................................................................................................381 12.2 Reference Standards and Protocols..............................................................................................................382 12.3 Availability...................................................................................................................................................383 12.4 Principles......................................................................................................................................................384 12.4.1 IPv6 Addresses....................................................................................................................................384 12.4.2 IPv6 Characteristics.............................................................................................................................387 12.4.3 IPv6 Packet Format.............................................................................................................................389 12.4.4 ICMPv6...............................................................................................................................................392 12.4.5 Neighbor Discovery.............................................................................................................................393 12.4.6 Path MTU............................................................................................................................................396 12.4.7 Dual Protocol Stacks...........................................................................................................................396 12.4.8 TCP6....................................................................................................................................................397 12.4.9 UDP6...................................................................................................................................................398 12.4.10 RawIP6..............................................................................................................................................398 12.5 IPv6 Features Supported by the MA5600T/MA5603T................................................................................399 12.5.1 Routing................................................................................................................................................400 12.5.2 ACLv6.................................................................................................................................................401 12.5.3 DHCPv6 Relay....................................................................................................................................403 12.5.4 MAC Address Binding........................................................................................................................405 12.5.5 Anti-IP Spoofing..................................................................................................................................406 12.5.6 DAD Proxy..........................................................................................................................................407 12.5.7 ARP/ND Proxy Response....................................................................................................................408 12.6 Application...................................................................................................................................................409 12.7 Terms and Abbreviations..............................................................................................................................410
13 Multicast....................................................................................................................................412
13.1 Introduction..................................................................................................................................................413 13.2 Specifications................................................................................................................................................413 13.3 Reference Standards and Protocols..............................................................................................................414 13.4 Availability...................................................................................................................................................415 13.5 Multicast Overview......................................................................................................................................415 13.6 Implementation Principle of Multicast.........................................................................................................420 13.6.1 Basic Managed Objects.......................................................................................................................420 13.6.2 Forwarding Framework on the Device................................................................................................422 13.6.3 IGMP Control Framework...................................................................................................................423 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xii
Contents
13.6.4 Multicast Forwarding Flow.................................................................................................................425 13.7 Advanced Multicast Technologies...............................................................................................................428 13.7.1 Multicast Service.................................................................................................................................428 13.7.2 Protocol Interoperation........................................................................................................................440 13.7.3 Network-side Interoperating Technologies.........................................................................................448 13.7.4 User-side Interoperating Technologies................................................................................................460 13.7.5 Interoperating Technologies Between Specific Ends..........................................................................466 13.8 Multicast Fault Diagnosis.............................................................................................................................470 13.9 Multicast QoS...............................................................................................................................................472 13.10 Network Application..................................................................................................................................473
14 Network Protection Features.................................................................................................474

14.1 Ethernet Link Aggregation...........................................................................................................................475 14.1.1 Introduction.........................................................................................................................................475 14.1.2 Specifications.......................................................................................................................................476 14.1.3 Reference Standards and Protocols.....................................................................................................477 14.1.4 Availability..........................................................................................................................................477 14.1.5 Feature Enhancements.........................................................................................................................479 14.1.6 Principle...............................................................................................................................................479 14.1.6.1 Introduction to LACP.................................................................................................................479 14.1.6.2 Principle of Implementing Link Aggregation............................................................................481 14.1.6.3 Principle of Implementing Inter-Board Aggregation.................................................................483 14.1.7 Network Applications..........................................................................................................................483 14.1.8 Term, Acronyms, and Abbreviations..................................................................................................488 14.2 Protection Group of Uplink Ports.................................................................................................................489 14.2.1 Introduction.........................................................................................................................................489 14.2.2 Specifications.......................................................................................................................................490 14.2.3 Availability..........................................................................................................................................490 14.2.4 Principle...............................................................................................................................................490 14.3 Smart Link and Monitor Link.......................................................................................................................492 14.3.1 Introduction.........................................................................................................................................492 14.3.2 Specifications.......................................................................................................................................492 14.3.3 Availability..........................................................................................................................................493 14.3.4 Principle...............................................................................................................................................493 14.3.4.1 Smart Link..................................................................................................................................493 14.3.4.2 Monitor Link...............................................................................................................................496 14.3.5 Network Applications..........................................................................................................................498 14.3.6 Glossary, Acronyms, and Abbreviations.............................................................................................499 14.4 MSTP............................................................................................................................................................499 14.4.1 Introduction.........................................................................................................................................500 14.4.2 Specifications.......................................................................................................................................500 14.4.3 Reference Standards and Protocols.....................................................................................................500 14.4.4 Availability..........................................................................................................................................501 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xiii
Contents
14.4.5 Principle...............................................................................................................................................501 14.5 RRPP............................................................................................................................................................505 14.5.1 Introduction.........................................................................................................................................505 14.5.2 Specifications.......................................................................................................................................506 14.5.3 Reference Standards and Protocols.....................................................................................................507 14.5.4 Availability..........................................................................................................................................507 14.5.5 Principle...............................................................................................................................................508 14.5.5.1 RRPP Network Topology...........................................................................................................508 14.5.5.2 RRPP Packet...............................................................................................................................510 14.5.5.3 RRPP Basic Principle.................................................................................................................513 14.5.5.4 Working Principle of RRPP.......................................................................................................516 14.5.6 Network Applications..........................................................................................................................518 14.5.7 Glossary, Acronyms and Abbreviations..............................................................................................520 14.6 BFD..............................................................................................................................................................521 14.6.1 Overview.............................................................................................................................................521 14.6.2 Specifications.......................................................................................................................................521 14.6.3 References...........................................................................................................................................521 14.6.4 Key Concepts.......................................................................................................................................522 14.6.5 BFD for IP...........................................................................................................................................525 14.6.6 Application Environment....................................................................................................................525 14.6.6.1 BFD for USR..............................................................................................................................525 14.6.6.2 BFD for OSPF............................................................................................................................526 14.6.6.3 BFD for IS-IS.............................................................................................................................526 14.6.7 Glossary, Acronyms, and Abbreviations.............................................................................................527 14.7 STM-1 Port Protection Switching................................................................................................................528 14.7.1 Introduction.........................................................................................................................................528 14.7.2 Specifications.......................................................................................................................................528 14.7.3 Reference Standards and Protocols.....................................................................................................529 14.7.4 Availability..........................................................................................................................................529 14.7.5 Principle...............................................................................................................................................529 14.7.6 Glossary, and Acronyms and Abbreviations.......................................................................................530 14.8 Type C Protection of GPON Lines...............................................................................................................531 14.8.1 Introduction.........................................................................................................................................531 14.8.2 Specifications.......................................................................................................................................531 14.8.3 Reference Standards and Protocols.....................................................................................................532 14.8.4 Availability..........................................................................................................................................532 14.8.5 Principle...............................................................................................................................................533 14.9 GPON Port 1+1 Backup...............................................................................................................................534 14.9.1 Introduction.........................................................................................................................................534 14.9.2 Specifications.......................................................................................................................................534 14.9.3 Reference Standards and Protocols.....................................................................................................535 14.9.4 Availability..........................................................................................................................................535 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xiv
Contents
14.9.5 Principle...............................................................................................................................................535
15 Voice Feature............................................................................................................................538
15.1 Introduction..................................................................................................................................................539 15.2 Specifications................................................................................................................................................539 15.3 Availability...................................................................................................................................................542 15.4 ISDN.............................................................................................................................................................542 15.4.1 Introduction.........................................................................................................................................543 15.4.2 Reference Standards and Protocols.....................................................................................................544 15.4.3 Basic principles....................................................................................................................................545 15.4.4 The Principles of ISDN BRA..............................................................................................................548 15.5 MGCP Voice Services..................................................................................................................................549 15.5.1 Introduction.........................................................................................................................................549 15.5.2 Reference Standards and Protocols.....................................................................................................550 15.5.3 Principle...............................................................................................................................................551 15.5.3.1 MGCP-Based VoIP....................................................................................................................551 15.5.3.2 MGCP-Based MoIP....................................................................................................................553 15.5.3.3 MGCP-Based FoIP.....................................................................................................................554 15.6 H.248 Voice Services...................................................................................................................................556 15.6.1 Introduction.........................................................................................................................................556 15.6.2 Reference Standards and Protocols.....................................................................................................557 15.6.3 Working Principle ...............................................................................................................................557 15.6.3.1 Mechanism of the H.248 Protocol..............................................................................................557 15.6.3.2 H.248-Based VoIP......................................................................................................................561 15.6.3.3 H.248-Based MoIP.....................................................................................................................563 15.6.3.4 H.248-Based FoIP......................................................................................................................563 15.7 SIP Voice Services.......................................................................................................................................563 15.7.1 Introduction.........................................................................................................................................564 15.7.2 Reference Standards and Protocols.....................................................................................................566 15.7.3 Principle...............................................................................................................................................566 15.7.3.1 SIP User Identification...............................................................................................................566 15.7.3.2 SIP Message Format...................................................................................................................567 15.7.3.3 User Registration Flow...............................................................................................................568 15.7.3.4 Call Flow of the VoIP (SIP) Calling Party.................................................................................570 15.7.3.5 Call Flow of the VoIP (SIP) Called Party..................................................................................572 15.7.3.6 Call Releasing Flow....................................................................................................................574 15.7.3.7 SIP-Based FoIP...........................................................................................................................574 15.7.3.8 SIP-Based MoIP.........................................................................................................................580 15.8 Key Voice Feature........................................................................................................................................581 15.8.1 Introduction.........................................................................................................................................582 15.8.2 Codec and Packetization Duration .....................................................................................................582 15.8.3 Echo Canceller.....................................................................................................................................583 15.8.4 Non-Linear Processor..........................................................................................................................584 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xv
Contents
15.8.5 VAD.....................................................................................................................................................585 15.8.6 Packet Loss Concealment....................................................................................................................585 15.8.7 Jitter Buffer..........................................................................................................................................586 15.8.8 Dual Tone Multi Frequency................................................................................................................586 15.8.9 Tone Playing........................................................................................................................................587 15.8.10 Voice Quality Enhancement..............................................................................................................588 15.8.11 Fax/Modem Quality Enhancement....................................................................................................588 15.8.12 RFC2833 Encryption.........................................................................................................................590 15.8.13 RTCP XR...........................................................................................................................................591 15.9 Voice Interface Feature.................................................................................................................................591 15.9.1 Introduction.........................................................................................................................................591 15.9.2 Ringing................................................................................................................................................591 15.9.3 Interface Protection..............................................................................................................................592 15.9.4 Features of the Voice Line Interface...................................................................................................593 15.10 Voice Test and Maintenance......................................................................................................................596 15.10.1 Introduction.......................................................................................................................................596 15.10.2 Loop Line Test and Circuit Test........................................................................................................596 15.10.3 Search Tone.......................................................................................................................................601 15.10.4 Signal Tone Test................................................................................................................................601 15.10.5 Call Emulation Test...........................................................................................................................602 15.10.6 RTCP Statistics..................................................................................................................................602 15.10.7 Remote Packet Capture.....................................................................................................................603 15.10.8 ToolBox.............................................................................................................................................604 15.10.9 QoS Alarm.........................................................................................................................................606 15.11 Voice Reliability.........................................................................................................................................606 15.11.1 Introduction.......................................................................................................................................606 15.11.2 Working Principle .............................................................................................................................606 15.11.2.1 H.248/MGCP Dual Homing.....................................................................................................607 15.11.2.2 H.248 Multi-homing.................................................................................................................608 15.11.2.3 Emergency Standalone.............................................................................................................611 15.11.2.4 SIP Dual Homing......................................................................................................................613 15.11.2.5 H.248/SIP over SCTP...............................................................................................................613 15.11.2.6 SIP over TCP............................................................................................................................614 15.11.2.7 Voice QoS.................................................................................................................................614
16 Device Management Security...............................................................................................618

16.1 Introduction..................................................................................................................................................620 16.2 Relevant Standards and Protocols................................................................................................................620 16.3 Availability...................................................................................................................................................621 16.4 SNMP...........................................................................................................................................................622 16.4.1 Introduction.........................................................................................................................................622 16.4.2 Specifications.......................................................................................................................................623 16.4.3 SNMP Network Management Model..................................................................................................624 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xvi
Contents
16.4.4 SNMP MIB..........................................................................................................................................625 16.4.5 SNMP SMI..........................................................................................................................................625 16.4.6 Working Principle of SNMPv1...........................................................................................................625 16.4.7 Working Principle of SNMPv2c..........................................................................................................629 16.4.8 Working Principle of SNMPv3...........................................................................................................629 16.4.9 Comparison Between SNMP Protocols in Security............................................................................630 16.5 Inband Management VPN............................................................................................................................631 16.5.1 Introduction.........................................................................................................................................632 16.5.2 Principles.............................................................................................................................................632 16.6 SSH...............................................................................................................................................................633 16.6.1 Introduction.........................................................................................................................................633 16.6.2 Specifications.......................................................................................................................................634 16.6.3 SSH Working Principle.......................................................................................................................634 16.6.4 SSH-based Encryption for Remote Management Connection............................................................635 16.6.5 SSH-based Encryption for File Transfer.............................................................................................635 16.7 User Management.........................................................................................................................................636 16.7.1 Introduction.........................................................................................................................................637 16.7.2 Specifications.......................................................................................................................................637 16.7.3 Principle...............................................................................................................................................637 16.8 Remote Connection Security........................................................................................................................638 16.8.1 Introduction.........................................................................................................................................638 16.8.2 Specifications.......................................................................................................................................638 16.8.3 Principle...............................................................................................................................................639 16.9 Log Management .........................................................................................................................................639 16.9.1 Introduction.........................................................................................................................................639 16.9.2 Principle...............................................................................................................................................639 16.10 Version and Data Management..................................................................................................................640 16.10.1 Introduction.......................................................................................................................................640 16.10.2 Specifications.....................................................................................................................................640 16.10.3 Principle.............................................................................................................................................641 16.11 Alarm and Event Management...................................................................................................................643 16.11.1 Introduction.......................................................................................................................................643 16.11.2 Specifications.....................................................................................................................................643 16.11.3 Principle.............................................................................................................................................643 16.12 Glossary, Acronyms, and Abbreviations....................................................................................................644
17 Network Security.....................................................................................................................645
17.1 Introduction..................................................................................................................................................646 17.2 Availability...................................................................................................................................................646 17.3 Anti-DoS Attack...........................................................................................................................................647 17.3.1 Introduction.........................................................................................................................................647 17.3.2 Specifications.......................................................................................................................................648 17.3.3 Principle...............................................................................................................................................648 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xvii
Contents
17.4 Anti-ICMP/IP Attack....................................................................................................................................648 17.4.1 Introduction.........................................................................................................................................648 17.4.2 Principle...............................................................................................................................................649 17.5 Source Route Filtering..................................................................................................................................649 17.5.1 Introduction.........................................................................................................................................649 17.5.2 Principle...............................................................................................................................................649 17.6 MAC Address Filtering................................................................................................................................649 17.6.1 Introduction.........................................................................................................................................650 17.6.2 Specifications.......................................................................................................................................650 17.6.3 Principle...............................................................................................................................................650 17.7 Firewall Blacklist..........................................................................................................................................650 17.7.1 Introduction.........................................................................................................................................650 17.7.2 Specifications.......................................................................................................................................651 17.7.3 Principle...............................................................................................................................................651 17.8 Configuration of Acceptable or Refused Address Segments.......................................................................651 17.8.1 Introduction.........................................................................................................................................651 17.8.2 Specifications.......................................................................................................................................652 17.8.3 Principle...............................................................................................................................................652 17.9 Service Overload Control.............................................................................................................................652 17.9.1 Introduction.........................................................................................................................................652 17.9.2 Availability..........................................................................................................................................653 17.9.3 Principle...............................................................................................................................................653 17.10 Acronyms and Abbreviations.....................................................................................................................658
18 Application Security...............................................................................................................659
18.1 Introduction..................................................................................................................................................661 18.2 Relevant Standards and Protocols................................................................................................................661 18.3 Availability...................................................................................................................................................662 18.4 HWTACACS................................................................................................................................................664 18.4.1 Introduction.........................................................................................................................................664 18.4.2 Specifications.......................................................................................................................................664 18.4.3 Principle...............................................................................................................................................665 18.5 RAIO............................................................................................................................................................667 18.5.1 Introduction.........................................................................................................................................667 18.5.2 Specifications.......................................................................................................................................668 18.5.3 Principle...............................................................................................................................................668 18.6 PITP..............................................................................................................................................................676 18.6.1 Introduction.........................................................................................................................................676 18.6.2 Specifications.......................................................................................................................................677 18.6.3 Principle...............................................................................................................................................677 18.7 DHCP option82............................................................................................................................................679 18.7.1 Introduction.........................................................................................................................................679 18.7.2 Specifications.......................................................................................................................................680 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xviii
Contents
18.7.3 Principle...............................................................................................................................................680 18.8 802.1X..........................................................................................................................................................682 18.8.1 Introduction.........................................................................................................................................682 18.8.2 Specifications.......................................................................................................................................682 18.8.3 Principle...............................................................................................................................................683 18.9 Anti MAC Spoofing.....................................................................................................................................684 18.9.1 Introduction.........................................................................................................................................685 18.9.2 Specifications.......................................................................................................................................685 18.9.3 Impact of MAC Spoofing....................................................................................................................686 18.9.4 MAC Address Binding........................................................................................................................686 18.9.5 Anti MAC Duplicate...........................................................................................................................687 18.10 Anti-IP Spoofing.........................................................................................................................................687 18.10.1 Introduction.......................................................................................................................................687 18.10.2 Specifications.....................................................................................................................................688 18.10.3 Principle.............................................................................................................................................688 18.11 User Isolation..............................................................................................................................................689 18.11.1 Introduction.......................................................................................................................................689 18.11.2 Specifications.....................................................................................................................................689 18.11.3 Principle.............................................................................................................................................689 18.12 Line Security of the GPON System............................................................................................................690 18.12.1 Introduction.......................................................................................................................................690 18.12.2 Specifications.....................................................................................................................................690 18.12.3 Principle.............................................................................................................................................690 18.13 Glossary, Acronyms, and Abbreviations....................................................................................................691
19 Line Optimization and Line Test.........................................................................................692

19.1 Line Optimization.........................................................................................................................................693 19.1.1 Introduction.........................................................................................................................................693 19.1.2 Specifications.......................................................................................................................................693 19.1.3 Reference.............................................................................................................................................694 19.1.4 Availability..........................................................................................................................................694 19.1.5 Principle...............................................................................................................................................695 19.1.6 Glossary, Acronyms, and Abbreviations.............................................................................................696 19.2 SELT Test.....................................................................................................................................................697 19.2.1 Introduction.........................................................................................................................................697 19.2.2 Specifications.......................................................................................................................................697 19.2.3 Availability..........................................................................................................................................698 19.2.4 Principle...............................................................................................................................................698 19.3 MELT...........................................................................................................................................................699 19.3.1 Introduction.........................................................................................................................................699 19.3.2 Specifications.......................................................................................................................................700 19.3.3 Availability..........................................................................................................................................701 19.3.4 Principle...............................................................................................................................................701 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xix
Contents
20 Operation and Maintenance..................................................................................................703

20.1 Introduction..................................................................................................................................................704 20.2 Reference Standards and Protocols..............................................................................................................704 20.3 Remote Operation.........................................................................................................................................704 20.3.1 Introduction.........................................................................................................................................704 20.3.2 Principle...............................................................................................................................................705 20.4 Ring Check...................................................................................................................................................705 20.4.1 Introduction.........................................................................................................................................705 20.4.2 Specifications.......................................................................................................................................706 20.4.3 Availability..........................................................................................................................................706 20.4.4 Principle...............................................................................................................................................706 20.5 ANCP............................................................................................................................................................709 20.5.1 Introduction.........................................................................................................................................709 20.5.2 Specifications.......................................................................................................................................709 20.5.3 Reference Standards and Protocols.....................................................................................................710 20.5.4 Availability..........................................................................................................................................710 20.5.5 Principle...............................................................................................................................................711 20.5.6 Glossary, Acronyms, and Abbreviations.............................................................................................720 20.6 Environment Monitoring..............................................................................................................................720 20.6.1 Introduction.........................................................................................................................................720 20.6.2 Specifications.......................................................................................................................................721 20.6.3 Availability..........................................................................................................................................721 20.6.4 Principle...............................................................................................................................................721 20.7 Power Saving and Maintenance...................................................................................................................724 20.7.1 Overview of the Power Saving and Maintenance Feature...................................................................724 20.7.2 Power Saving.......................................................................................................................................724 20.7.2.1 Introduction................................................................................................................................724 20.7.2.2 Availability.................................................................................................................................725 20.7.2.3 Principle......................................................................................................................................725 20.7.3 Maintenance.........................................................................................................................................728 20.7.3.1 Introduction................................................................................................................................729 20.7.3.2 Principle......................................................................................................................................729 20.7.4 Glossary...............................................................................................................................................730 20.8 ONT DHCP Simulation................................................................................................................................730 20.8.1 Introduction.........................................................................................................................................731 20.8.2 Specifications.......................................................................................................................................732 20.8.3 Reference Standards and Protocols.....................................................................................................732 20.8.4 Availability..........................................................................................................................................732 20.8.5 Principle...............................................................................................................................................734
21 Ethernet OAM..........................................................................................................................736
21.1 Introduction..................................................................................................................................................737 21.2 Reference Standards and Protocols..............................................................................................................737 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xx
Contents
21.3 Ethernet CFM OAM.....................................................................................................................................737 21.3.1 Introduction.........................................................................................................................................737 21.3.2 Specifications.......................................................................................................................................738 21.3.3 Availability..........................................................................................................................................739 21.3.4 Principle...............................................................................................................................................741 21.4 Ethernet EFM OAM.....................................................................................................................................745 21.4.1 Introduction.........................................................................................................................................745 21.4.2 Availability..........................................................................................................................................747 21.4.3 Principle...............................................................................................................................................747 21.5 Glossary, Acronyms, and Abbreviations......................................................................................................750
22 Redundancy Backup of the Control Boards.......................................................................753

22.1 Introduction..................................................................................................................................................754 22.2 Specifications................................................................................................................................................754 22.3 Availability...................................................................................................................................................754 22.4 Principle........................................................................................................................................................754
23 Clock Feature............................................................................................................................756
23.1 NTP...............................................................................................................................................................757 23.1.1 Introduction.........................................................................................................................................757 23.1.2 Specifications.......................................................................................................................................757 23.1.3 Reference Standards and Protocols.....................................................................................................757 23.1.4 Availability..........................................................................................................................................758 23.1.5 Principle...............................................................................................................................................758 23.2 Clock and Time System................................................................................................................................759 23.2.1 Introduction.........................................................................................................................................759 23.2.2 Specifications.......................................................................................................................................760 23.2.3 Reference Standards and Protocols.....................................................................................................761 23.2.4 Availability..........................................................................................................................................763 23.2.5 Enhancement.......................................................................................................................................763 23.2.6 Principle of the Clock and Time System.............................................................................................763 23.2.6.1 Clock/Time Synchronization Source..........................................................................................764 23.2.6.2 Configuring the System Phase-Locked Loop.............................................................................765 23.2.6.3 Clock/Time Output.....................................................................................................................765 23.2.6.4 Working Principle of Clock........................................................................................................767 23.2.7 Scenarios of Clock/Time Synchronization..........................................................................................768 23.2.7.1 Applications of Clock Output.....................................................................................................768 23.2.7.2 Clock Synchronization of the Native TDM Service...................................................................769 23.2.7.3 SAToP Clock Synchronization...................................................................................................772 23.2.7.4 Clock Synchronization of the Synchronization Ethernet Service...............................................776 23.2.8 Glossary, Acronyms, and Abbreviations.............................................................................................778
24 The Feature of LAN Interface Boards..................................................................................781

24.1 ETHB Board Feature....................................................................................................................................782 Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xxi
Contents
24.1.1 Introduction.........................................................................................................................................782 24.1.2 Specifications.......................................................................................................................................783 24.1.3 Reference Standards and Protocols.....................................................................................................783 24.1.4 Availability..........................................................................................................................................783 24.1.5 Principle...............................................................................................................................................784 24.2 SPUA............................................................................................................................................................786 24.2.1 Introduction.........................................................................................................................................786 24.2.2 Specifications.......................................................................................................................................787 24.2.3 Principle...............................................................................................................................................788 24.3 GIU Board Feature.......................................................................................................................................792 24.3.1 Introduction.........................................................................................................................................792 24.3.2 Specifications.......................................................................................................................................792 24.3.3 Reference Standards and Protocols.....................................................................................................792 24.3.4 Availability..........................................................................................................................................793 24.3.5 Principle...............................................................................................................................................793 24.3.6 Glossary, Acronyms, and Abbreviations.............................................................................................800
Issue 01 (2011-10-30)
xxii
1 GPON
1
About This Chapter
1.1 Introduction 1.2 Specifications 1.3 Reference Standards and Protocols 1.4 Availability 1.5 Overview of the GPON System 1.6 GPON Principle 1.7 Key GPON Technologies 1.8 GPON Terminal Authentication and Management
GPON
Gigabit passive optical network (GPON) is one of the PON technologies. A GPON-capable device supports high-bandwidth transmission. GPON effectively solves the bandwidth bottleneck problem in the twisted-pair access and meets users demands on high-bandwidth services.
1.9 Continuous-Mode ONU Detection The GPON system supports detection of a continuous-mode ONU to ensure that the GPON system runs properly and does not get into disorder because of the continuous-mode ONU. 1.10 GPON Network Applications 1.11 Glossary, Acronyms, and Abbreviations
Issue 01 (2011-10-30)
1 GPON
1.1 Introduction
Definition
xPON is a type of point to multi-point (P2MP) passive optical network (PON). The gigabitcapable passive optical network (GPON) is standardized by the ITU-T Recommendations G. 984.x. It supports the upstream rate of 1.25 Gbit/s and downstream rate of 2.5 Gbit/s. A typical PON system consists of: l l l Optical line terminal (OLT) Optical network unit (ONU) Optical distribution network (ODN)
The ODN connects the OLT to the ONU.
Purpose
GPON adopts the passive optical transmission technology and is mainly applicable to such scenarios as fiber to the home (FTTH), fiber to the building (FTTB), fiber to the office (FTTO), and fiber to the mobility base station (FTTM) to provide various services: l l l l l Voice Data Video Leased line Distributed service
GPON supports high-bandwidth transmission. This helps break the bandwidth bottleneck of the access over twisted pairs and achieve bandwidth-eating services, such as high-definition TV (HDTV) and live programs. In addition, GPON supports long-reach access, which helps extend the coverage and reduce network nodes.
1.2 Specifications
The specifications of the GPON boards and ports are as follows: l The system supports the service shelf to be fully configured with the GPBC/GPBD board (every GPBC board supports four GPON ports and every GPBD board supports eight GPON ports). Every GPBC/GPBD supports up to 8K service streams. Every GPON port on GPBC supports up to 64 ONUs. Every GPON port on GPBD supports up to 128 ONUs. The system supports up to 8,192 ONUs. The GPON port supports maximum downstream and upstream rates of 2.5 Gbit/s and 1.25 Gbit/s respectively.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2
l l l l l
Issue 01 (2011-10-30)
1 GPON
l l l l
The system supports a maximum physical transmission distance of 20 km and a maximum logical transmission distance of 60 km. The GPON board supports the query of the CPU usage. The system supports the query of the alarm information about a PON port on the GPON board through the CLI. The system supports five types of power budget for the GPON port: CLASS A,CLASS B,CLASS B+,CLASS C, and CLASS C+. CLASS B+ is in most common use and CLASS C+ is used in some long-distance transmission scenarios. CLASS B+ achieves the optical power budget of 28.5 dB, slightly smaller than that of CLASS C+ (up to 32 dB).
The system supports the following GEM port and T-CONT specifications: l l l l The system supports the GEM encapsulation. Every GPON port supports up to 4096 GEM ports and the maximum number of GEM ports supported in the system is 32K. The system supports up to 512 DBA profiles and 32K T-CONTs. The system supports the loop line detection for the remote GEM port and the line detection for the ONT UNI port. The system can automatically allocate GEM port IDs.
The system supports the following GPON terminal management specifications: l l l l l l l l l l l l l l l l l Supports activating/deactivating ONU. Supports resetting ONU. Supports automatically issuing the configuration of the ONUs that go online again. Supports obtaining the version information about ONUs. Supports displaying the status of the physical ports of ONUs. Supports monitoring the optical fiber receive and transmit power of ONUs. Supports reporting the alarms of ONUs. Supports displaying the information about the optical transceiver of the ONT. Supports time synchronization between the ONT and the OLT through the extended OMCI. Supports enabling/disabling the BPDU transparent transmission function for an ONT or an Ethernet port of an ONT. Supports VLAN and priority switching for a port of an ONT. Supports VLAN switching for upstream IGMP packets of an ONT. Supports configurable ONT queue scheduling modes. Supports setting the multicast snooping mode for an ONT. Supports enabling/disabling the MAC address learning function for an ONT through the extended OMCI. Supports the standard OMCI protocol defined by the ITU-T and also the GPON interoperability standard defined by China Telecom. Supports loopback on the ETH port and the E1 port of the ONU.
The system supports the following GPON QoS specifications:

H805GPBD, H802GPBD, H802EPBC, H802EPBD and H805EPBD support ONU-based CAR. (H805GPBD supports ONU-based CAR by ONU-based traffic shaping.)
Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 3
1 GPON
1.3 Reference Standards and Protocols

GPON technical standards are researched by Full Service Access Networks (FSAN) and officially released by ITU-T. FSAN is established in 1995 in response to the initiatives of seven major network carriers, and aims to propose an optical access solution and formulate standards associated with the optical access equipment, so that the standard-compliant equipment can provide the voice, data, and video services. GPON standards mainly include: l l ITU-T G.984.1: General Characteristics. This protocol mainly describes the basic features and major protection modes of GPON. ITU-T G.984.2: Physical Media Dependent (PMD) Layer Specification. This protocol mainly describes the PMD layer parameters, including physical parameters (such as the transmit optical power, receiver sensitivity, and overload optical power) of optical transceivers, and also defines optical budget of different levels, for example, the most common Class B+. ITU-T G.984.3: Transmission Convergence Layer Specification. This protocol mainly describes the TC layer specifications, including the upstream and downstream frame structures and GPON principle. ITU-T G.984.4: ONT Management And Control Interface Specification. This protocol mainly describes the GPON management and maintenance protocols, such as OAM, PLOAM, and OMCI. ITU-T G.984.5: Enhancement Band. This protocol mainly describes the GPON wavelength planning, including reserving bands for next-generation PON. ITU-T G.984.6: Reach Extension. This protocol mainly describes several long reach PON schemes for extending GPON transmission distance. TR-156: Using GPON Access in the context of TR-101.
l l l
1.4 Availability
License Support
The number of remote ONT ports supported by the MA5600T/MA5603T is licensed. Therefore, the corresponding service is also licensed.
Version Support
Table 1-1 Version Support Product MA5600T/ MA5603T Version V800R006C02 and later versions
Issue 01 (2011-10-30)
1 GPON
Hardware Support
l l Boards supporting this feature are GPBC and GPBD. The terminals must support GPON upstream transmission.
1.5 Overview of the GPON System

Introduction to the PON System
PON is the short form for passive optical network. It adopts a point-to-multipoint (P2MP) network architecture. A PON network consists of three parts: the optical line terminal (OLT), optical distribution network (ODN), and optical network units (ONUs). l l l The OLT is an aggregation device located at the central office (CO) for terminating the PON protocol. ONUs are located on the user side, providing various types of ports for connecting to user terminals. The OLT and ONUs are connected through a passive ODN for communication. The ODN is composed of passive optical components such as optical fibers, and one or more passive optical splitters. The ODN provides optical channels between the OLT and ONUs. It interconnects the OLT and ONUs and is highly reliable.
Figure 1-1 shows the architecture of a PON network. A PON network differs from the traditional broadband access network in that PON transmits data using optical fibers. Also, a PON network can connect a large number of access users, requires less optical fiber resources, and supports a high access rate. Figure 1-1 PON network
Passive Optical Network ONU
Passive Optical Splitter
OLT
Passive Optical Splitter
Mainstream PON technologies include broadband passive optical network (BPON), Ethernet passive optical network (EPON), and gigabit passive optical network (GPON). Adopting the ATM encapsulation mode, BPON is mainly used for carrying ATM services. With the obsolescence of the ATM technology, BPON also drops out. EPON is an Ethernet passive optical network technology. GPON is a gigabit passive optical network technology and is to date the most widely used mainstream optical access technology.
1 GPON
Introduction to the GPON System

GPON is a PON technology. GPON supports an upstream rate of 1.25 Gbit/s and downstream access rate of 2.5 Gbit/s, and also supports ultra-long transmission with a maximum physical reach of 20 km and maximum logical reach of 60 km. At the same time, GPON supports a 1:64 split ratio, which can be extended to 1:128 and enables GPON to support a large number of users and cover a wide area. Figure 1-2 shows the working principle of the GPON network. Figure 1-2 Working principle of the GPON network
1490nm
ODN OLT 1310nm ONU/ONT
In the GPON network, the OLT is connected to the optical splitter through a single optical fiber, and the optical splitter is then connected to ONUs. Different wavelengths are adopted in the upstream and downstream directions for transmitting data. The upstream wavelength is 1310 nm and downstream wavelength is 1490 nm. The GPON adopts WDM to transmit data of different upstream/downstream wavelengths over the same ODN. Data is broadcast in the downstream direction and transmitted in the TDMA mode (based on timeslots) in the upstream direction. All data is broadcast to all ONUs from the OLT. The ONUs then select and receive their respective data and discard the other data. Figure 1-3 shows the details. Figure 1-3 Downstream communication principle of GPON
1 ONU1 2 ONU2 3
3 2 1
3 2 1
1
Splitter OLT
3 ONU3
Issue 01 (2011-10-30)
1 GPON
In the upstream direction, each ONU can send data to the OLT only in the timeslot permitted and allocated by the OLT. This ensures that each ONU sends data in a given sequence, thus avoiding upstream data conflicts. Figure 1-4 shows the details. Figure 1-4 Upstream communication principle of GPON
1 ONU1 2 ONU2 3 ONU3 2

3
Splitter OLT
1.6 GPON Principle

Basic GPON Concepts
In the GPON system, a GPON encapsulation mode (GEM) frame is the smallest service-carrying unit and the most basic encapsulation structure. All service streams are encapsulated into the GEM frame and transmitted over GPON lines. The service streams are identified by GEM ports and every GEM port is identified by a unique Port-ID. The Port-ID is globally allocated by the OLT. That is, the ONUs connected to the OLT cannot use GEM ports that have the same PortID. The GEM port is used to identify the virtual service channel that carries the service stream between the OLT and the ONU. It is similar to the VPI/VCI of the ATM virtual connection. T-CONT: a service carrier in the upstream direction in the GPON system. All GEM ports are mapped to T-CONTs. Then, service streams are transmitted upstream by means of the OLT's DBA scheduling. T-CONT is the basic control unit of the upstream service stream in the GPON system. Every T-CONT is identified by Alloc-ID. The Alloc-ID is globally allocated by the OLT. That is, every T-CONT can be used by only one ONU connected to the OLT. There are five types of T-CONT; therefore, T-CONT selection varies during the scheduling of different types of upstream service streams. Every T-CONT bandwidth type has its own quality of service (QoS) feature. QoS is mainly represented by the bandwidth guarantee, which can be classified as fixed, assured, non-assured, best-effort, and hybrid mode (corresponding to type 1type 5 in Table 1-2).
Issue 01 (2011-10-30)
1 GPON
Table 1-2 T-CONT types Bandwidth Type Fixed Bandwidth Assured Bandwidth Maximum Bandwidth T-CONT Type Type 1 X No Z=X Type 2 No Y Z=Y Type 3 No Y Z>Y Type 4 No No Z Type 5 X Y ZX+Y
NOTE
In Table 1-2, X indicates the fixed bandwidth value, Y the assured bandwidth value, and Z the maximum bandwidth value.
Figure 1-5 shows the principle of service multiplexing in the GPON system. On ONUs, all service streams are mapped to different GEM ports and then to different types of T-CONTs for upstream transmission (the T-CONT is the basic carrier in the upstream direction over GPON lines). On the OLT, the T-CONT demodulates GEM ports therein and sends them to the GPON MAC chip. The MAC chip demodulates service streams in the GEM port payload and then sends them to a proper service processing unit for processing. In the downstream direction, all service streams are encapsulated by the GPON service processing unit into GEM ports and then GEM ports are broadcast to all ONUs connected to the GPON port. Then, every ONU filters data according to GEM port ID, reserving the GEM port corresponding to itself. After that, every ONU decapsulates service streams from the GEM port and sends them to the user-side equipment through the service interface of the ONU. Figure 1-5 Principle of service multiplexing in the GPON system
ONU GEM port T-CONT
OLT
GEM port T-CONT
Figure 1-6 and Figure 1-7 shows the mapping between service stream, GEM port, and T-CONT. The GEM port is the smallest service unit in the GPON system. Every GEM port can carry one
1 GPON
or more types of service stream. The GEM port, after carrying service streams, must be mapped to a T-CONT before upstream service scheduling. Every ONU supports multiple T-CONTs and can be configured with different service types. A T-CONT can be bound with one or more GEM ports, depending on the user's configuration. On the OLT, GEM ports are demodulated from the T-CONT and then service streams are demodulated from the GEM port payload for further processing. Figure 1-6 GPON service mapping relationship (Downstream)
Port Port Port Port Port PON OLT Port Port Port Port Port
GEM Port filter
ONU
GEM Port filter

GEM Port filter
ONU
ONU
Issue 01 (2011-10-30)
1 GPON
Figure 1-7 GPON service mapping relationship (Upstream)

Port T-CONT ONU T-CONT PON Port ONU T-CONT Port Port Port Port Port Port
ONU
T-CONT
Port
Identified by ONU-ID
Identified by Alloc -ID
Identified by Port-ID
GPON Frame Structure

Figure 1-8 shows the GPON frame structure. The GPON downstream frame is invariably 125 s long and it comprises Physical Control Block downstream (PCBd) and Payload. PCBd mainly consists of the GTC header and the upstream bandwidth map (BWmap). The GTC header is mainly used for performing frame delimitation, clock synchronization, and FEC. The BWmap is mainly used for notifying every ONU of its upstream bandwidth allocation, thereby determining the start and end timeslots of the T-CONT corresponding to every ONU in the upstream transmission process. In this way, all ONUs send data according to timeslots uniformly specified by the OLT and data collision is avoided. In the upstream direction, service scheduling is performed in the TDMA mode according to T-CONT. All ONUs connected to a GPON port share the upstream bandwidth and send their data upstream at their own timeslots according to the BWmap requirements. At the same time, every ONU reports its status of data to be sent to the OLT through the upstream frame. Then, the OLT uses DBA to allocate upstream timeslots to ONUs and sends updates in every frame.
Issue 01 (2011-10-30)
10
1 GPON
Figure 1-8 GPON frame structure

Downstream framing 125 s Physical Control Block Downstream (PCBd) Upstream Bandwidth Map ONU AllodID 257 Start 100 End 200 AllodID 258 Start 300 End 500 OLT Payload
T-CONT1 (ONT 1) Slot 100 PLOu PLOAMu Slot 200 PLSu DBRu Slot 300
T-CONT 2 (ONT 2) Slot 500 Payload y
Payload x DBRu Y
Upstream framing
NOTE
l PLOu: Physical Layer Overhead upstream l PLOAM: Physical Layer OAM l PLOAMu: PLOAM upstream l PLSu: Power Levelling Sequence upstream l DBRu: Dynamic Bandwidth Report upstream l The current application is: l GPBC: Alloc-ID = T-CONT ID x 256 + ONU ID l GPBD: When T-CONT ID < 8, Alloc-ID = T-CONT ID x 256 + ONU ID. When T-CONT ID 8, Alloc-IDs are assigned automatically from the first idle Alloc-ID.
The lengths of the upstream frame and downstream frame at each GPON rate are the same. Every upstream frame contains the content carried by one or more T-CONTs. The BWmap in each downstream frame identifies the start time and end time of each T-CONT transmission. An ONU must send a PLOu each time before the ONU receives the media access right to PON from another ONU. If an ONU is allocated two consecutive Alloc-IDs (the end time of one is smaller by 1 than the start time of the other), the ONU must not send the PLOu of the second Alloc-ID. The payload of an upstream frame may contain three types of content: the ATM cell, the GEM frame, and the DBA report. Figure 1-9 shows the GPON upstream frame structure.
Issue 01 (2011-10-30)
11
1 GPON
Figure 1-9 GPON upstream frame structure

Upstream Frame
PLOu
PLO DB DB PLSu Payload X Payload Y AMu RuX RuY
PLOu
DB Payload Z RuZ
ONU A
ONU B
The GPON upstream frame consists of the PLOu, PLOAMu, PLSu, DBRu, and Payload fields and the meanings of these fields are described as follows: l l PLOu: physical control header, mainly used for frame delimitation, synchronization, and indication of which ONU the current frame targets at. PLOAMu: PLOAM message of upstream data, mainly used for reporting management information such as ONU maintenance and management status. (Not every frame has such a field. This field may not be sent but needs to be negotiated.) PLSu: Power Levelling Sequence upstream. It is a 120-byte field and is used for power control measurements by the ONU. DBRu: mainly used for reporting the T-CONT status for applying for bandwidth and completing dynamic bandwidth allocation for ONUs next time. (Not every frame has such a field. This field may not be sent but needs to be negotiated.) Payload: DBA status report or data frame. The data frame may be GEM header or frame. GEM header: mainly used for differentiating data of different GEM ports. The GEM port is the smallest unit for data transmission in the GPON system, which is similar to the PVC of ATM. Every type of upstream service stream must be mapped to the GEM port and then to the T-CONT for transmission. The GEM header field consists of PLI, Port ID, PTI, and HEC. PLI: Indicates the length of data payload. Port ID: Uniquely identifies a GEM port. PTI: Identifies the payload type. It is mainly used for identifying the status and type of data that is being transmitted (for example, whether the OAM message is being transmitted and whether data transmission is complete). HEC: Provides the FEC function and transmission quality. GPON supports a downstream transmission rate of 2.488 Gbit/s, a frame length of 38880 bytes, and a frequency of one frame every 125 s, as shown in Figure 1-10 and Figure 1-11.
l l
l l
Issue 01 (2011-10-30)
12
1 GPON
Figure 1-10 GPON downstream frame structure
PCBd n
Payload
PCBd n+1
Payload
n+1
PCBd n+2
125us
"Pure" ATM cells Section N * 53 bytes
TDM & Data Fragments over GEM Section
Figure 1-11 PCBd structure

PCBd Payload
PSync 4 bytes
Ident 4 byte
PLOAMd 13 bytes
BIP PLend PLend 1 byte 4 bytes 4 bytes
US BW Map N*8bytes
Coverage of this BIP
Coverage of next BIP
The OLT broadcasts PCBd to all ONUs. Every ONU receives the entire PCBd and then acts upon the relevant information contained therein. A PCBd contains information such as frame synchronization information, physical layer OAM information, and BIP check field. US BWMap (upstream bandwidth map) is the upstream transmission bandwidth map sent to each T-CONT by the OLT. The bandwidth map is transmitted through the US BW Map field in the PCBd of the downstream frame. In this way, MAC control is implemented. GPON uses TDM for the upstream transmission. Therefore, when multiple ONUs transmit data upstream concurrently, transmission conflicts occur. The avoidance mechanism for such a conflict is that the OLT sends a notification through the downstream frame, informing each ONU of its corresponding timeslot for upstream transmission.
1.7 Key GPON Technologies

Key GPON technologies include the burst optical/electrical technology, ranging, forward error correction (FEC), line encryption, and dynamic bandwidth allocation (DBA).
Burst Optical/Electrical Technology

The GPON system is a point to multi-point (P2PM) network. A GPON port on the OLT side can connect to 64 ONUs through optical splitters. In the GPON system, all data is broadcast
1 GPON
downstream to ONUs. This requires not only OLT-side optical transceivers to send optical signals continuously but ONU-side optical transceivers to receive optical signals continuously. In the upstream direction, the GPON system uses the time division multiple access (TDMA) technology. That is, every ONU sends data at its own allocated timeslot and disables its optical transceiver (that is, stop sending optical signals) at timeslots allocated to other ONUs, thereby avoiding affecting other ONUs. The OLT then receives the upstream data of every ONU in a burst manner according to timeslots. Hence, to ensure the normal running of the GPON system, OLT-side optical transceivers must support the burst receiving of upstream data sent by ONUs, and ONU-side optical transceivers are able to send data upstream in a burst manner.
Ranging
Generally, ranging is enabled when an ONU is registered for the first time. In a GPON system, TDMA is adopted when multiple ONUs send data to an OLT. That is, only one ONU under a PON port can send data to the OLT at a time; otherwise, data collisions occur. To avoid such collisions, the logical distance between each ONU and the OLT must be measured to calculate the equalization delay (EqD) of each ONU so that the time for ONUs to send data is controlled by the OLT. By ranging, the OLT obtains the RTD of each ONU and then calculates their EqDs to ensure that Teqd = RTD + EqD for each ONU. Teqd is short for the equalized round trip delay, which is preset in the system and is equal to or larger than the RTD of the logically farthest ONU. Each ONU delays the upstream data transmission, in reference to the downstream phase, based on the value of the assigned EqD. This is to avoid the collisions between the upstream data of different ONUs. Figure 1-12 shows the ranging method. Figure 1-12 GPON ranging
Issue 01 (2011-10-30)
14
1 GPON
l l l
Pre-assigned EqD: default EqD preset on an ONU Zero-distance equalization delay: Teqd preset in the system Assigned equalization delay: EqD when an ONU functions properly
FEC
Forward error correction (FEC) is mainly used for improving the transmission quality of a line. FEC uses RS (255, 239), performing an FEC encoding of all downstream packets every 255 bytes. This ensures the correctness of data received by the ONUs. By using the FEC algorithm at the transport layer, the GPON system achieves the reduced bit error rate (from 10-3 to 10-12) of line transmission, avoids data retransmission, and improves the optical power budget by 2-3 dB. Upstream FEC and downstream FEC are supported in the GPON system.
Line Encryption
In the GPON system, downstream data is broadcast to all ONUs. As a result, downstream data destined for certain ONUs or all ONUs may be intercepted by illegal users. At the same time, the GPON system is uniquely and highly data-directional. Therefore, almost every ONU cannot intercept the upstream data of other ONUs, thus allowing some private information (such as key) to be safely transmitted in the upstream direction. The GPON system uses the line encryption technology to solve the security issues. l Encryption system The GPON system uses AES128 encryption for line security control, thereby effectively preventing security issues such as data embezzlement. In the AES128 encryption system, the OLT supports key exchange and switchover. l Key exchange The key exchange is initiated by the OLT. The OLT does so by sending a key exchange request. The ONU responds by generating and sending the key to the OLT. Because the PLOAM (Physical Layer OAM) message is limited in length, the key is sent in two parts. The two parts of the key are sent three times repeatedly. If the OLT has not received the key for any of the three times, it will re-send the key exchange request until it receives the same key all three times the key is sent. When the OLT receives a new key, it starts the key switching. The OLT notifies the ONU by sending a command containing the frame number of the new key. This command will be sent for three times. As long as the ONU receives the command once, it will switch the check key on proper data frames.
DBA
In the GPON system, the OLT controls an ONU's upstream data traffic by sending authorization signals to the ONU. PON requires an effective TDMA mechanism to control the upstream traffic, so that data packets from multiple ONUs do not collide when packets are transmitted upstream. Nevertheless, the collision-based mechanism requires QoS management in an optical distribution network (ODN), a passive network. This is physically impossible, or causes severe efficiency decrease. Due to the above-mentioned reason, a mechanism for management of the upstream GPON traffic has been a primary focus in standardization of GPON traffic management. It drives the development of the ITU-TG.983.4 Recommendation, which defines the dynamic bandwidth allocation (DBA) protocol for management of the upstream PON traffic. Figure 1-13 shows the DBA principle. The GPON system controls the upstream traffic by allocating data authorization to each transmission container (T-CONT) inside the ONU. The OLT needs to know the traffic status of a T-CONT to determine the authorized amount to be
1 GPON
allocated to the T-CONT. By using the DBRu field or the Payload field in the upstream frame, the ONUs report their data statuses to the OLT. After receiving ONUs' data statuses, the OLT uses DBA to periodically update the upstream BWmap information according to the status of ONU data waiting to be sent and notifies all ONUs of the updates through the downstream frame. Thus, every ONU can dynamically adjust its upstream bandwidth according to the actual data traffic to be sent, thereby improving the utilization of upstream bandwidth. Figure 1-13 DBA principle
ONU DBA report Control plane BW Map T-CONT DBA algorithm logic OLT
Time slot
Data plane
Scheduler
1.8 GPON Terminal Authentication and Management

GPON Terminal Authentication
GPON terminal authentication is a mechanism in which an OLT authenticates an ONU according to the authentication information reported by the ONU and in this way denies access to unauthorized ONUs. In the GPON system, only authenticated ONUs can access the system. Implementing authentication meets the carriers' requirements for flexible management and easy maintenance. ONUs to be authenticated can be classified into two types: ONUs (automatically discovered ONUs) that are not preconfigured on the OLT and ONUs that are preconfigured on the OLT. Figure 1-14 shows the authentication process of an ONU that is not preconfigured.
Issue 01 (2011-10-30)
16
1 GPON
Figure 1-14 Authentication process of an ONU that is not preconfigured
ONU DS Frame with valid Psync
OLT O1: Initial state Upstream_Overhead PLOAM SN _Request(BWMap) O2: Standby state
Serial_Number_ONU PLOAM The OLT assigns a temporary ONU ID when the SN is not Assign ONU_ID configured on the OLT. O3: Serial number state
Ranging request Ranging response O4: Ranging state
Ranging time
Request password
Password The OLT sends a deregister message to the ONU when the password is not configured on the OLT and automatic discovery is not enabled on the PON port. O5: Operation state
The ONU returns to the O2 state.
As shown in the preceding figure, after receiving downstream traffic following its power-on, the ONU responds to the SN request message sent from the OLT. The OLT, upon receiving the SN from the ONU, finds that the SN is not configured and assigns a temporary ONU ID to the ONU. After the ONU enters the operation state, the OLT sends a password request message to the ONU. The ONU then responds with a password. When finding that the password is not configured on the OLT and that the automatic discovery function is not enabled on the PON port
1 GPON
to which the ONU is connected, the OLT sends a deregister message to the ONU. Upon receiving this message, the ONU sends a register request message to the OLT. A preconfigured ONU can be authenticated in five modes: SN, SN+password, password, logical ONU ID (LOID), and LOID+CheckCode (CC). l SN authentication In SN authentication, the OLT matches only the ONU SN. Figure 1-15 shows the process of SN authentication. Figure 1-15 SN authentication
OLT
O1: Initial state Upstream_Overhead PLOAM SN _Request(BWMap) O2: Standby state
Serial_Number_ONU PLOAM
SN is matched. Assign ONU_ID
O3: Serial number state
Ranging time
Normal-state ONU
Normal-state OLT
After receiving the SN response message from the ONU, the OLT checks whether an ONU with the same SN is already online. If yes, the OLT reports an SN conflict alarm to the CLI or NMS. If no, the OLT directly assigns the user-defined ONU ID to the ONU.
1 GPON
After the ONU enters the operation state, the OLT does not send a password request message to this ONU. Instead, the OLT directly configures a GEM port for the ONU for carrying OMCI messages, and allows the ONU to go online. The GEM port can be automatically configured by the OLT so that the OMCI-carrying GEM port has the same ID as the ONU ID. In addition, the OLT reports an ONU online alarm to the CLI or NMS. l SN+password authentication In SN+password authentication, the OLT matches both the ONU SN and password. Figure 1-16 shows the process of SN+password authentication.
Issue 01 (2011-10-30)
19
1 GPON
Figure 1-16 SN+password authentication
Serial_Number_ONU PLOAM O3: Serial number state SN is matched.
Assign ONU_ID
Ranging time
Request password Password Password is matched. Normal-state ONU Normal-state OLT O5: Operation state
After receiving the SN response message from the ONU, the OLT checks whether an ONU with the same SN is already online. If yes, the OLT reports an SN conflict alarm to the CLI or NMS. If no, the OLT directly assigns the user-defined ONU ID to the ONU. After the ONU enters the operation state, the OLT sends a password request message to the ONU, and compares the password reported by the ONU with the password configured on the OLT. If the passwords are the same, the OLT checks whether an ONU
1 GPON
authenticated by the same SN+password is already online. If yes, the OLT reports a password conflict alarm to the CLI or NMS. If no, the OLT directly configures a GEM port for the ONU for carrying OMCI messages, and allows the ONU to go online. In addition, the OLT reports an ONU online alarm to the CLI or NMS. If the passwords are different, the OLT does not report an ONU automatic discovery message even if the ONU automatic discovery function is enabled on the PON port to which this ONU is connected. Instead, the OLT sends a Deactivate_ONU-ID PLOAM message to deregister the ONU. l Password authentication Password authentication includes two modes: always-on and once-on. An ONU that uses password authentication is added to a PON port on an OLT in advance, and then this ONU is connected to the PON port. In once-on mode, the aging-time is configurable, ranging from 1 hour to 168 hours. After the aging-time is set, the ONU must register with the OLT and go online within the preset aging time. Otherwise, the ONU is not allowed to register with the OLT or go online. Once the ONU is authenticated, its SN cannot be modified. In once-on mode, only the initial authentication of an ONU is by password, as shown in Figure 1-17. In subsequent authentications, the ONU is authenticated by SN or SN+password according to the CLI configuration, as shown in Figure 1-15 or Figure 1-16. Once-on mode is applied in the following scenario: The carrier allocates a password to the user, and the user must go online within the specified time. After going online, the user cannot change the ONU. To change the ONU, the user must notify the carrier of this requirement.
Issue 01 (2011-10-30)
21
1 GPON
Figure 1-17 Initial ONU authentication in once-on mode
Serial_Number_ONU PLOAM For the ONU that goes online for the first time, the OLT records the ONU SN. Assign ONU_ID Ranging request Ranging response O4: Ranging state O3: Serial number state
Ranging time
Request password Password Password is matched. Normal-state ONU Normal-state OLT
O5: Operation state
In always-on mode, there is no restriction on the time when the user goes online. An ONU is authenticated by password when it goes online for the first time. After the ONU passes the password authentication and goes online successfully, the OLT generates an SN+password entry according to the SN and password of the ONU. If it is not the first time that an ONU goes online, and if the SN and password of the ONU are the same as the SN and password of the ONU that successfully goes online for the first time, the ONU is authenticated by SN+password. If the user needs to replace the ONU with an ONU that has the same password but a different SN, the ONU after the replacement will be authenticated by password. After this ONU passes authentication and goes online
1 GPON
successfully, the original SN+password entry is updated. Therefore, in the always-on mode, the ONU can go online at any time if its password is correct. Figure 1-18 shows the process of ONU authentication in always-on mode. The always-on mode is applied in the following scenario: The carrier allocates a password to the user, and the user can use different ONUs with different SNs, as long as the user uses the same password. As such, the user can change the ONU without informing the carrier. Figure 1-18 ONU authentication in always-on mode
Serial_Number_ONU PLOAM Assign ONU_ID Ranging request Ranging response
O3: Serial number state
O4: Ranging state
Ranging time
Request password Password Password is matched. Normal-state ONU Normal-state OLT O5: Operation state
In password authentication, if finding that the SN or password of the ONU to be authenticated conflicts with that of an online ONU, the OLT deregisters the ONU to be authenticated. This does not affect the online ONU. In once-on mode, before the registration of the ONU times out or before the ONU successfully registers with the OLT for the first time, the ONU discovery status is
1 GPON
ON (only the ONU whose discovery status is ON is allowed to register with the OLT and go online). After the registration of the ONU times out or after the ONU successfully registers with the OLT for the first time, the OLT sets the discovery status of the ONU to OFF. The ONU whose registration times out is not allowed to register with the OLT or go online. In this case, the registration timeout flag of the ONU needs to be reset at the central office (CO), and then the ONU can go online. An ONU that successfully registers for the first time is allowed to register and go online again. l LOID+CC authentication LOID+CC authentication is defined by the CTC2.1 standard of China Telecom. In this authentication mode, LOID has 24 bytes, and CC has 12 bytes and is optional. Based on this authentication mode, China Telecom defines a new GPON OMCI entity for GPON LOID+CC authentication. Figure 1-19 shows the process of GPON LOID+CC authentication. Figure 1-19 GPON LOID+CC authentication
OSS LOID (24) CC (12)
NMS
LOID (24)
CC (12)
OLT
LOID (24)
CC (12)
OMCI: last 10 bytes of the LOID

PW (10)
OMCI: (LOID,CC)
LOID (24)
CC (12)
GPON ONT (Password authentication)
GPON ONT (LOID authentication)
In GPON LOID+CC authentication: 1. The OLT obtains LOID+CC (configured on the ONT web page) of an ONT and matches the information against related information on the OLT. If the information is matched, the ONT passes the authentication. If the information is not matched, the OLT obtains the password of the ONT and compares it with the last 10 bytes of the LOID. If the information is matched, the ONT passes the authentication.
2.
Issue 01 (2011-10-30)
24

NOTE
1 GPON
l In data planning, ensure that the last 10 bytes of different LOIDs are not duplicated. l LOID authentication and rogue ONU detection are mutually exclusive. The two functions cannot be enabled at the same time. l If the LOID input is shorter than 24 bytes or CC shorter than 12 bytes, the system automatically appends ASCII character NUL (0x00 in hexadecimal notation) at the end of the LOID or CC. l If LOID authentication is not available on the ONT web page, use the last 10 bytes of the LOID as the GPON password and input this value on the password authentication web page for authentication.
GPON Terminal Management

The ONUs in a GPON system are managed through physical layer OAM (PLOAM) messages and OMCI messages. PLOAM messages are mainly used for communicating the management and maintenance information, such as the DBA information and DBRu information, at the GPON physical layer and TC layer. OMCI messages are mainly used for managing and maintaining the service layer, such as discovering the hardware capability of equipment, maintaining various alarm information, and configuring service capabilities. OMCI messages fully comply with the ITU-T G.984.4 Recommendations.
NOTE
The PLOAM protocol is defined in ITU-T G.984.3 and is used for maintenance and management at the physical layer. OMCI is a master-slave management protocol. The OLT is the master device and the ONU is the slave device. The OLT controls multiple downstream ONUs through OMCI channels.
1.9 Continuous-Mode ONU Detection

The GPON system supports detection of a continuous-mode ONU to ensure that the GPON system runs properly and does not get into disorder because of the continuous-mode ONU.
Introduction
The continuous-mode ONU detection is a feature for detecting and isolating ONUs that send optical signals in timeslots other than specified. This feature is also called rogue ONU detection. GPON uses time division multiplexing (TDM) mechanism in the upstream direction. Every ONU sends data upstream to the OLT at its own timeslot allocated by the OLT. If an ONU sends optical signals at other ONUs' timeslots, the optical signals of the ONU will conflict with those sent by other ONUs. As a result, communication of a certain other ONU or all the ONUs is affected. Such an ONU that sends optical signals upstream not at its allocated timeslot is called a rogue ONU. There are many types of rogue ONUs. Based on the time of optical signal transmission, rogue ONUs can be classified as: l l Continuous-mode ONUs: ONUs transmitting optical signals continuously. After spotting a continuous-mode ONU, the OLT issues an instruction to isolate this ONU. Irregular-mode ONUs: ONUs transmitting optical signals in a period other than specified, such as at a premature time or in a prolonged period.
Currently, the OLT detects only continuous-mode ONUs.

1 GPON
Continuous-Mode ONU Detection Procedure

OLT detection consists of two parts: 1. The OLT detects a rogue ONU and then isolates the ONU to ensure the normal services of other ONUs. 2. The OLT reports information about the faulty ONU to the NMS and through the NMS the OAM personnel can rectify the faulty ONU in time. Figure 1-20 shows the procedure for the OLT's detecting a rogue ONU. Figure 1-20 OLT's detecting a rogue ONU
OLT starts checking for continuous-mode ONU
OLT periodically opens the window to check GPON signals
Is any optical signal received? Yes OLT enables the continuousmode ONU detection function OLT checks ONUs one by one
No
OLT deletes the error alarm
Is the check completed?
No
Yes OLT identifies the faulty ONU
1.
The OLT opens a blank window in the GPON upstream direction every fifteen minutes to detect upstream optical signals sent by ONUs. At this moment, the OLT starts the rogue ONU detection process if still receiving upstream optical signals. If the OLT does not receive any upstream optical signals, it indicates that no rogue ONU exists in the system or that the previously reported alarm is an error.
Issue 01 (2011-10-30)
1 GPON
2.
In the rogue ONU detection process, the OLT broadcasts messages to all the ONUs connected to a PON port to disable the optical transceivers of the ONUs, that is, to instruct them not to send upstream optical signals. Then, the OLT opens a window to detect upstream optical signals again. If the OLT still receives upstream optical signals sent by ONUs, it indicates that a third-party ONU is connected to the PON port and that this ONU does not respond to the instruction issued by the OLT. In this case, the OLT enters the special processing state and clears the alarm. If the OLT does not receive any upstream optical signals, it starts to check the ONUs one by one. The OLT issues proper commands to the ONUs, instructing their optical transceivers to send upstream optical signals one by one. In this way, the OLT checks whether it can receive upstream optical signals and whether the other ONUs go offline after an ONU starts to send optical signals. If the other ONUs all go offline after an ONU starts to send optical signals, it indicates that the ONU is a continuous-mode ONU, that is, a rogue ONU. Continuousmode ONU detection is performed on all the ONUs connected to the PON port. This ensures that all rogue ONUs are searched out. After spotting a rogue ONU, the OLT issues proper commands to disable the optical transceiver of the ONU so that the ONU does not send upstream optical signals. If the optical transceiver of an ONU is disabled by the OLT, the ONU cannot send upstream optical signal permanently (even after the ONU is reset or is restarted after power-off) until the OLT issues proper commands to enable the ONU to resume sending upstream optical signals. This mechanism ensures rogue ONUs are isolated thoroughly. Troubleshoot the faulty ONU.
NOTE
3.
4.
5.
If the ONU nearest to the PON port of the OLT is working in the continuous mode, the other ONUs connected to the PON port will go offline. If an ONU relatively far away from the PON port of the OLT is working in the continuous mode, the other ONUs that have slightly weaker optical signal strength than the ONU will go offline.
Limitations and Restrictions

1. The OLT checks and analyzes the abnormality in the sending of upstream optical signal over a PON line, and identifies and isolates rogue ONUs of only non-malicious users. This feature does not apply to the intentionally sabotaged ONU or sub-standard ONU. 2. To detect whether a continuous-mode ONU exists over a PON line, the ONU may not support the extended PLOAM message defined by Huawei. In this case, the continuous-mode ONU can only be detected but cannot be located. 3. To detect a specific continuous-mode ONU connected to a PON port, all the ONUs connected to the PON port must support the extended PLOAM message defined by Huawei and their optical transceivers can be enabled or disabled. 4. When an unconfigured ONU connected to a PON port is working in the continuous mode, all the other unconfigured ONUs connected to the PON port cannot be automatically discovered. 5. A continuous-mode ONU (rogue ONU) must be able to parse and correctly respond to the downstream PLOAM message.
Issue 01 (2011-10-30)
27
1 GPON
1.10 GPON Network Applications

FTTx Network Applications
By adopting GPON, the OLT and ONUs (or ONTs) can implement various FTTx network applications such as FTTH, FTTO, FTTB, FTTC, and FTTM, as shown in Figure 1-21. Figure 1-21 FTTx network applications
FTTM BTS E1 FE/GE Node B ONU Multicast-Server GE/10GE iManager U2000
E1/POTS FTTO PBX FE/GE ONU SDH/Metro Splitter OLT STM-1/E1 Enterprise HQ NGN/IMS
Enterprise Router
FTTB/FTTC
ONU FTTH E1/GE
ONT
GPON Protection
In GPON applications, Type B can be implemented, as shown in Figure 1-22.
Issue 01 (2011-10-30)
28
1 GPON
Figure 1-22 Type B protection
ONU1 Optical splitter
Backbone optical fiber protection
OLT
ONU2
Active Standby
Type B protection protects different PON ports of the same OLT.
1.11 Glossary, Acronyms, and Abbreviations

Glossary
Term Rogue ONU Explanation An ONU that sends optical signals continuously or irregularly in timeslots other than specified.
Acronyms and Abbreviations

Acronym/Abbreviation OLT ONT ONU ODN Full Spelling Optical line terminal Optical network terminal Optical network unit Optical distribution network
Issue 01 (2011-10-30)
29
2 P2P Optical Access
2
About This Chapter
P2P Optical Access
Point-to-point (P2P) optical access means the point-to-point FTTx access based on the combination between its P2P optical access board and the ONUs. 2.1 P2P FE Optical Access Point-to-point (P2P) Ethernet optical access refers to the P2P FTTH access provided by the P2P Ethernet optical access board and the ONT, which meets the requirements for the application of the next generation access device under the integration of video, voice, and data services. 2.2 GE P2P Optical Access The OPGD, OPFA, SPUA, and ETHB boards supports P2P optical access. Among these boards, the OPFA implements FE optical access, and the OPGD, SPUA, and ETHB boards implement GE optical access. In the following, description will focus on the applications of the OPGD board.
Issue 01 (2011-10-30)
30
2.1 P2P FE Optical Access

Point-to-point (P2P) Ethernet optical access refers to the P2P FTTH access provided by the P2P Ethernet optical access board and the ONT, which meets the requirements for the application of the next generation access device under the integration of video, voice, and data services.
2.1.1 Introduction
Definition
Point-to-point (P2P) FE optical access means the point-to-point FTTH access provided by the MA5600T/MA5603T based on the combination between its P2P FE optical access board and the ONTs.
Purpose
P2P FE optical access solution provides P2P FTTH access services. It is especially suitable for the residential neighborhoods with fiber to the home, and can provide the bandwidth of 100 Mbit/s to satisfy the users' requirements for the next generation access equipment which integrates video, voice, and data services.
2.1.2 Specifications
The MA5600T/MA5603T supports the following P2P FE optical access specifications: l l l l l Every OPFA board supports up to 16 100 Mbit/s FE optical ports. MA5600T: A service subrack can be configured with up to 16 OPFA boards, providing up to 256 FE optical ports. MA5603T: A service subrack can be configured with up to 6 OPFA boards, providing up to 96 FE optical ports. Every port supports up to eight traffic streams. Supports the function of synchronizing Ethernet packets.
2.1.3 Reference Standards and Protocols

For the standards compliance of the P2P FE optical access feature, see "Standards Compliance" in the MA5600T/MA5603T Product Description.
2.1.4 Availability
License Support
The feature of P2P FE optical access is the basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Version Support
Table 2-1 Version Support Product MA5600T/ MA5603T Version V800R006C02 and later
Feature Dependency
A GE optical port cannot be used for P2P FE optical access.
Hardware Support
The OPFA board and the FE ONTs need to support the feature of P2P FE optical access.
2.1.5 Principle
Figure 2-1 shows the implementation of the P2P FE optical access. Figure 2-1 Implementation of P2P FE optical access
OLT SCU
OPFA
......
OPFA
FE P2P ONT STB
Phone
PC
IPTV
The upstream packets sent from the user end are processed as follows: 1. After modulation on the ONT, the upstream packets are sent to the OPFA board of the MA5600T/MA5603T through a fiber.
Issue 01 (2011-10-30)
2.
The OPFA board processes the upstream packets according to the user's configuration, and then sends the processed packets to the control board of the MA5600T/MA5603T through the backplane bus. After receiving the packets, the control board forwards the packets to the upper layer network through the upstream port.
3.
The downstream packets sent from the network end are processed as follows: 1. 2. 3. The downstream packets from the upper layer network reach the control board of the MA5600T/MA5603T through the upstream port. The control board forwards the packets to the OPFA interface board through the backplane bus according to the learning results during the upstream forwarding. The OPFA board processes the downstream packets, and sends the processed packets to the user end.
2.2 GE P2P Optical Access

The OPGD, OPFA, SPUA, and ETHB boards supports P2P optical access. Among these boards, the OPFA implements FE optical access, and the OPGD, SPUA, and ETHB boards implement GE optical access. In the following, description will focus on the applications of the OPGD board.
2.2.1 Introduction
Definition
GE point-to-point (P2P) Ethernet optical access is a mode in which P2P Ethernet optical access boards provide GE ports and coordinate with downstream devices to implement various optical access solutions for users. The solutions include FTTC/FTTB, FTTH, FTTO, and FTTM. The OPGD board is a new GE P2P optical access board developed for V800R008 and is mainly used for FTTH household user access and for DSLAM convergence. The OPGD board also supports FTTM (mobile bearing) and FTTO (enterprise users).
Purpose
P2P optical access boards prior to OPGD include OPFA, ETHB, and SPUA. The following table lists the ports provided and scenarios supported by each board. Compared with other P2P optical access boards, the OPGD board features more advantages for the access and the subtending scenarios.
Issue 01 (2011-10-30)
33
Board OPFA
Port 16 FE optical ports
Application Scenario It can be directly connected to home user terminal (ONT) only and does not support subtending or upstream transmission. It is connected to the ONT to implement FTTH and provides a 100 Mbit/s bandwidth to each household.
OPGD
48 GE optical ports
It supports the access and subtending scenarios and does not support upstream transmission. l In the access scenario, it is connected to the ONT to implement FTTH and provides a 1000 Mbit/s bandwidth to each household. l In the subtending scenario, it is connected to the DSLAM, CBU, or SBU to implement FTTC/ FTTB, FTTO, or FTTM respectively.
Issue 01 (2011-10-30)
34
Board ETHB
Port 8 GE optical/electrical ports
Application Scenario It supports subtending and upstream transmission, but cannot be directly connected to home user terminal. l In the subtending scenario, it is connected to the DSLAM to implement FTTC/FTTB. Through the convergence by the DSLAM, each GE port can provide services for a large number of users. l In the upstream transmission scenario, the ETHB board functions as a GIU upstream interface board. It extends the number of upstream ports in the system to increase the total upstream bandwidth of the system.
SPUA
8 GE optical ports+2 10GE optical ports
It supports subtending and upstream transmission, but cannot be directly connected to home user terminal. l In the subtending scenario, it is connected to the DSLAM to implement FTTC/FTTB. Through the convergence by the DSLAM, each GE port can provide services for a large number of users. l In the upstream transmission scenario, it provides a high upstream forwarding bandwidth. It implements upstream link backup by inter-board aggregation and interboard protect group.
The OPGD board provides GE P2P Ethernet optical access for more flexible FTTx solutions at higher bandwidth, lower costs, and higher reliability.
Issue 01 (2011-10-30)
35
Higher bandwidth. Traditional FE P2P optical access provides only a 100 Mbit/s transmission rate, but GE P2P optical access allows for 1000 Mbit/s. The FTTH solution implemented through GE P2P optical access can provide a higher bandwidth for users, thus meeting the requirements of high-end users. Lower costs. Compared with SPUA and ETHB, which are capable of both upstream transmission and subtending, the OPGD board is specially designed for subtending and access scenarios. The OPGD board provides 48 GE ports, so it can be subtended to more DSLAMs and hence reduces the costs of FTTC/FTTB networking. Higher reliability. The OPGD board allows a higher reliability in the DSLAM subtending scenario through features such as inter-board aggregation, smart link, and ring check. More flexible scenarios. The OPGD board coordinates with a variety of downstream devices (such as the DSLAM, ONT, SBU, and CBU) to implement FTTC/FTTB, FTTH, FTTO, and FTTM. An MA5600T/MA5603T configured with the OPGD board can not only be directly connected to access terminals but also subtend DSLAMs in order to converge a large number of users.
l l
Benefit
Benefits to carriers One MA5600T/MA5603T can support multi-access such as GPON, xDSL, and P2P. Such an All-in-one solution reduces the equipment CAPEX as well as OPEX for carriers. Benefits to users Because the OPGD board can provide high-density GE ports for subtending DSLAMs, which converge massive users, lower costs are needed for providing end-to-end service guarantee for VIP household and enterprise users. In residential communities where optical fibers are already deployed, a 1000 Mbit/s bandwidth can be provided for high-end users exclusively, meeting the user needs for HD video, voice, and data integrated services.
The OPGD board supports two application scenarios: access and subtending. l l l In the access scenario, the OPGD board is connected to the ONU to implement FTTH. In the subtending scenario, the OPGD board is connected to the DSLAM, CBU, or SBU to implement FTTC/FTTB, FTTO, or FTTM respectively. The two application scenarios cannot be implemented on the same OPGD board at the same time but can be implemented on different OPGD boards at the same time on the same OLT. To be specific, FTTH and other FTTx services such as FTTC cannot run on the same OPGD board at the same time, but FTTC/FTTB, FTTO, and FTTM services can run on the same OPGD board at the same time. FTTH and other FTTx services such as FTTC can run in the same OLT system at the same time. The scenarios can be switched by running the network-role command. By default, the OPGD board in the system runs in the access scenario.
The OPGD board supports different functions when running in the access scenario and subtending scenario. l l
Issue 01 (2011-10-30)
Functions Supported Only in the Access Scenario Functions Supported Only in the Subtending Scenario
Functions Supported in Both Scenarios
Functions Supported Only in the Access Scenario

The OPGD board supports IPoE, PPPoE, DHCP, and 802.1x user authentication modes. Detailed specifications are as follows: l l l l In the IPoE mode, a static IP address is directly specified for a user, and user packets are IPoE-encapsulated and sent to the access network. In the PPPoE mode, the OPGD board supports the PPPoE+ protocol, single-MAC mode, and multi-MAC mode. In the DHCP mode, the OPGD board supports Layer 2 forwarding, Layer 3 forwarding, DHCP proxy, and DHCP option 82. In the 802.1x mode, the OPGD board supports re-authentication, keep-alive handshake, quiet period, RFC 4014, EAP trunk and termination, 802.1x packet statistics collection, user traffic real-time statistics measurement, and RADIUS real-time accounting. The OPGD board supports logging of the last 1000 going online/offline events of DHCP and PPPoE users. The 1000 log entries can be shared systemwide.
The OPGD board supports flow bundle. The OPGD board supports the following security features: l l l l l l l l l Anti-DoS attack. The OPGD board limits the number of upstream protocol packets from users based on port to prevent users from attacking the network by DoS. Anti-MAC spoofing. The OPGD board limits the number of MAC addresses that a user can change within a short time. MAC address filter. The OPGD board limits the user packets carrying specified MAC addresses. VMAC. The OPGD board replaces untrustable user MAC addresses with trusted ones by means of 1:1 VMAC or N:1 VMAC. Anti-IP spoofing. The OPGD board limits the number of IP addresses that a user can change within a short time. IP address filter. The OPGD board permits or denies a user the access to the device according to the user IP address. Anti-ICMP attack. The OPGD board prevents users from attacking the network with ICMP packets. Anti-IP attack. The OPGD board prevents users from attacking the network with IP packets. IP binding based on stream. The OPGD board supports 2K service streams for IP binding.
Functions Supported Only in the Subtending Scenario

The OPGD board supports the following network protection features: l Supports aggregation of the OPGD boards in adjacent slots according to the following rules: On the MA5600T, the ID of the slot for a service board starts from 1. Therefore, two OPGD boards in slots 1-2, 3-4, or 5-6, ... can be aggregated. On the MA5603T, the ID of the slot for a service board starts from 0. Therefore, two OPGD boards in slots 0-1, 2-3, or 4-5, ... can be aggregated.
l l l l l l l
Supports aggregation groups. Multiple user ports can be added to an aggregation group. Each OPGD board supports up to 48 aggregation groups. Supports inter-board aggregation. User ports on aggregated OPGD boards can be added to the same aggregation group. Supports static LACP. Supports protect group, and supports inter-board protect group (including 1:1 protect group) for the ports on boards of the same type. Supports STP and MSTP. Supports ring check. This feature prevents broadcast packets from generating a storm in a ring network. Supports smart link and monitor link.
Supports synchronous Ethernet clock; does not support IEEE1588 V2 recovered clock. Supports transparent transmission of protocol packets. Supports transparent transmission of QinQ-encapsulated upstream and downstream user packets. Supports transparent transmission of the following protocol packets when the packets are not QinQ-encapsulated: BPDU, OSPF, RIP, VTP-CDP, ARP, IGMP, VBAS, PPPoE+, BGP, NTP, PIM, MPLS, ETHOAM, and LDP. Supports the following types of traffic streams on the multicast subtending port: l l Port+VLAN traffic streams Port+SVLAN+CVLAN traffic streams
NOTE
Other types of traffic stream cannot ensure normal multicast services on a subtending port.
Supports forwarding of dual-tagged multicast packets in the subtending scenario.
Functions Supported in Both Scenarios

NOTE
The following functions are supported in both the access and the subtending scenarios. Unless specified otherwise, the same function has the same specifications in both scenarios.
Each OPGD board supports 48 GE optical ports, providing 48 one-fiber bidirectional 1GE physical links or 24 two-fiber bidirectional 1GE physical links. Ports are numbered in different manners in the one-fiber mode and in the two-fiber mode. For details on the numbering methods, see "OPGD Board" in the Hardware Description. The OPGD board supports smart SFP optical modules. The OPGD board supports the IPoE, PPPoE, and 2000-byte super-long frame encapsulation formats for interface data, and does not support the IPoA, PPPoA, or over-2000-byte jumboframe encapsulation formats. The OPGD board supports the following specifications for the traffic classification feature. l l l
Issue 01 (2011-10-30)
Based on port. Classification parameter: port. Based on port and CVLAN. Classification parameters: port+VLAN. Based on port, CVLAN, and VLAN priority. Classification parameters: port+VLAN+PRI.
l l l
Based on port and packet type. Classification parameters: port+ETHERTYPE. Based on port, CVLAN, and packet type. Classification parameters: port+VLAN +ETHERTYPE. Based on port, SVLAN, and CVLAN. Classification parameters: port+SVLAN+CVLAN.
The OPGD board supports the following VLAN specifications. l Supports VLAN transforming based on service stream, transforming modes including: Transparent (C <-->C). The VLAN tag of a packet is not transformed; that is, the VLAN tag is transparently transmitted. Translate (C <--> S). The CVLAN tag of a packet is fixedly translated into an SVLAN tag. Translate-and-add (C <--> S+C'). The CVLAN tag of a packet is translated, and an SVLAN tag is added to the packet. Translate-double (S+C <--> S'+C'). Both the SVLAN and CVLAN of a packet are translated. Add (U <-->S; C <--> S+C). A VLAN tag is added to a packet in a mandatory manner. Add-double (U <--> S+C). Two VLAN tags are added to a packet in a mandatory manner. Translate-and-delete (S+C <--> C'). The CVLAN of a packet is translated and the SVLAN of the packet is deleted. l Supports the following VLAN forwarding modes: VLAN+MAC: Identifies the target port according to the SVLAN and DMAC of a packet. SVLAN+CVLAN: Identifies the target port according to the SVLAN and CVLAN of a packet.
NOTE
The VLAN+MAC and SVLAN+CVLAN forwarding modes take effect only on switch-oriented service streams. In the case of connection-oriented service streams, the target egress port is identified according to the stream information. For details on the implement principle, see 24.2.3 Principle.
l l
Supports inner tag check on downstream broadcast packets. Supports configuration of bridging based on VLAN. The bridging between user ports of the OPGD board is implemented through the control board. Users of the OPGD board cannot be bridged directly. Supports an isolation switch for configuring the isolation status of the ports on the OPGD board. By default, the ports are isolated from each other. The isolated ports cannot be bridged directly.
Supports the following QoS functions: l CAR specifications: Supports single rate three color marker (srTCM) and two rate three color marker (trTCM). Colors packets according to CAR results. Supports stream-based CAR and port+CoS-based CAR (only in the access scenario). l
Issue 01 (2011-10-30)
Supports color-based early drop.

l l l l
Supports PQ, WRR, and PQ+WRR queue scheduling; supports eight queues one each user port. Supports line rate (only in the subtending scenario) to implement rate limitation on egress port and ingress port. Supports IP traffic profile and inner and outer priority mapping. Supports queue shaping (only in the access scenario).
Supports the following ACL functions: l l Supports basic ACL, advanced ACL, link ACL, and user-defined ACL. Supports rate limitation, priority adjustment and statistics collection, and traffic suppression on broadcast, unknown multicast, and unknown unicast packets.
Supports the following multicast functions: l l l l Supports IGMP v2 and v3. Supports IGMP proxy and IGMP snooping. Supports distributed multicast. Supports configuration of the processing method (discard or forward) for upstream/ downstream unknown multicast packets.
Supports 802.1ag and 802.3ah Ethernet OAM.

The following lists the reference standards and protocols of the OPGD board: l l l l l IEEE 802.3z: 1000Base-SX and 1000Base-LX GE standard IEEE 802.1p: Layer 2 service priority QoS and CoS standard IEEE 802.1d: standard of MAC bridges IEEE 802.1q: VLAN definition standard IEEE 802.3x: standard of flow control in full duplex
2.2.4 Availability
Relevant NE
Implementing GE P2P Ethernet optical access requires the coordination between the OLT and ONUs. ONUs include ONT, DSLAM, CBU, and SBU.
License Support
GE P2P optical access is a basic feature of the MA5600T/MA5603T. Therefore, the corresponding service is provided without a license.
Issue 01 (2011-10-30)
40
Version Support
Table 2-2 Version Support Product MA5600T/ MA5603T U2000 Version V800R008C01 and later versions V100R002C01
Hardware Support
The ONU must support upstream transmission through GE.
2.2.5 Network Applications

Figure 2-2 shows the FTTx network application in the GE P2P Ethernet optical access mode. Figure 2-2 Network application in the GE P2P Ethernet optical access mode
IPTV server
MG Softswitch
NMS
BRAS LAN switch
FTTH ONT STB
GE
OLT
GE Phone PC IPTV
GE GE DSLAM xDSL CBU E1
SBU Laptop
LAN switch
Modem
STB
Phone
PC FTTO
PC
Phone
PC
IPTV
Laptop
Mobile
FTTC/FTTB
FTTM Fiber
Issue 01 (2011-10-30)
41
To meet the requirements of different scenarios, the OLT works with ONUs of various types to implement network applications in multiple optical access modes, such as FTTC/FTTB, FTTH, FTTO, and FTTM. The FTTx network applications in GE P2P Ethernet optical access have the following in common: The data, voice, and video signals of terminal users are sent to ONUs, where the signals are converted into Ethernet packets and then transmitted over optical fibers to the OLT through the GE upstream ports of the ONUs. Then, the Ethernet packets are forwarded to the upper-layer IP network through the upstream port of the OLT. The differences of the FTTx network applications in GE P2P Ethernet optical access are as follows: l FTTH: The OLT is connected to the ONUs at user premises through GE P2P Ethernet optical access. In this way, gigabit bandwidth is exclusively provided to each household. FTTH is applicable to new apartments or villas in loose distribution. In this scenario, FTTH provides services of higher bandwidth for high-end users. FTTB/FTTC: The OLT is connected to DSLAMs in corridors (FTTB) or by the curb (FTTC) through GE P2P Ethernet optical access. The DSLAMs are then connected to user terminals through xDSL. With the aggregation provided by the DSLAMs, one port on the OPGD board can be connected to a large number of users. FTTB/FTTC is applicable to densely-populated residential communities or office buildings. In this scenario, FTTB/ FTTC provides services of certain bandwidth for common users. FTTO: The OLT is connected to enterprise SBUs through GE P2P Ethernet optical access. The SBUs are connected to user terminals through FE, POTS, or Wi-Fi. QinQ VLAN encapsulation is implemented on the SBUs and the OLT. In this way, transparent and secure data channels can be set up between the enterprise private networks located at different places, and thus the service data and BPDUs between the enterprise private networks can be transparently transmitted over the public network. FTTO is applicable to enterprise networks. In this scenario, FTTO implements TDM PBX, IP PBX, and private line service in the enterprise intranets. FTTM: The OLT is connected to CBUs through GE P2P Ethernet optical access. The CBUs are then connected to wireless base stations through E1. The OLT connects wireless base stations to the core IP bearer network through optical access technologies. This implementation mode is not only simpler than traditional SDH/ATM private line technologies, but also drives down the costs of base station backhaul. FTTM is applicable to reconstruring and capacity expansion of mobile bearer networks. In this scenario, FTTM converges the fixed network and the mobile network on the bearer plane.
Network Protection
FTTC/FTTB, FTTO, and FTTM, compared with FTTH, involve a larger number of access users. Hence, network reliability must be ensured. The ONU provides dual upstream ports to implement link redundancy backup. With the coordination of the ONU, the OPGD board on the OLT supports the following link backup modes: inter-board aggregation, smart link, and monitor link. Inter-board aggregation: Two upstream ports of the ONU are respectively connected to two adjacent OPGD boards of the OLT. Dual upstream link aggregation is configured on the ONU, and a protect group is configured on the OLT. Thus, 1:1 backup of GE links can be implemented through inter-board aggregation. Figure 2-3 shows the network topology of the OLT subtending the ONU to implement inter-board aggregation. For more details on the network application of inter-board aggregation, see 14.1.7 Network Applications.
Figure 2-3 Network topology of inter-board aggregation

Upstream link aggregation Subsending port protect group
ONU OLT Master Slave
Smart link and monitor link: Two upstream ports of the ONU are respectively connected to the OPGD board on two OLTs. Monitor link is configured on the OLTs, and smart link is configured on the ONU. 1:1 GE link backup is implemented through a mode similar to type B dual homing of GPON ports. Figure 2-4 shows the network topology of the OLTs subtending the ONUs to implement smart link and monitor link. For more details on smart link and monitor link, see 14.3 Smart Link and Monitor Link. Figure 2-4 Network topology of smart link and monitor link
OLT1 Monitor Link group2
OLT2
Monitor Link group2
Smart Link group1
Smart Link group2
ONU1
ONU2 Master Slave
Issue 01 (2011-10-30)
43
3 ADSL2+ Access
3
About This Chapter
3.1 Introduction 3.2 Specifications 3.3 Reference 3.4 Availability 3.5 Principle 3.6 Glossary, Acronyms, and Abbreviations
ADSL2+ Access
Asymmetrical digital subscriber loop (ADSL) is an asymmetric transmission technology that is used to transmit data at high speed over the twisted pair. ADSL2+ is an extension of ADSL. The upstream rate of ADSL2+ reaches 2.5 Mbit/s, and the downstream rate reaches 24 Mbit/s. The maximum reach of ADSL2+ is 6.5 km.
Issue 01 (2011-10-30)
44
3 ADSL2+ Access
3.1 Introduction
Definition
Asymmetrical digital subscriber loop (ADSL) is an asymmetric transmission technology that is used to transmit data at high speed over the twisted pair. ADSL2+ is an extension of ADSL. The upstream rate of ADSL2+ reaches 2.5 Mbit/s, and the downstream rate reaches 24 Mbit/s. The maximum transmission distance of ADSL2+ is 6.5 km.
Purpose
The ADSL technology adopts asymmetric transmission to provide high-speed data access service.
3.2 Specifications
The MA5600T/MA5603T supports the following specifications: l l l l l l l l l l l l l l l l l l l Compatibility with ADSL and ADSL2 A maximum upstream rate of 2.5 Mbit/s A maximum downstream rate of 24 Mbit/s A maximum reach of 6.5 km Support for ADSL2+ board and POTS access Transmission mode (Annex A, Annex B, Annex L, Annex M and Annex J) Fast bit swap Power management, power cut back function on the CO and the CPE Automatic rate adjustment according to the line conditions during the initialization Pilot floating, pilot selection based on channel conditions Support for tone transmit power control based on CO-MIB (spectrum shaping Tssi) Dynamic seamless rate auto-sensing to improve the adaptability for line parameters Single ended loop test (SELT) Configuration, modification and query of the ADSL configuration parameters (such as line and spectrum) Report of alarm and maintenance information on the line and channel Support of 32 ports and 64 ports ADSL2+ boards Power-saving of the xDSL line Metallic Line Testing (MELT)(only supported by the ADKM) Two-pair ADSL2+ ATM bonding for H802ADKM and H802ADPD
NOTE
Only the bonding of the adjacent ports of a board is supported.
Support for the creation, modification and deletion of the bonding group profile. Support for the rate limitation and the rate monitoring of the bonding group.
3 ADSL2+ Access
l l l
Physical layer retransmission F5 OAM loopback (supported by ADPD and ADQD). Support for INM feature.
3.3 Reference
The following lists the reference documents of ADSL2+ access: l l l l l l l G992.1 Asymmetric digital subscriber line (ADSL) transceivers G992.3 Asymmetric digital subscriber line transceivers 2 (ADSL2) G992.5 Asymmetric Digital Subscriber Line (ADSL) transceivers - Extended bandwidth ADSL2 (ADSL2plus) Draft G.998.4 (for approval) Draft Amendment 1 to G.997.1 (FOR CONSENT) ITU-T G.998.1: ATM-based multi-pair bonding TR-159: Management Framework for xDSL Bonding
3.4 Availability
Hardware Support
l l l The ADIF/ADLF, ADPD/ADQD, ADKM, ADPE, and CAME boards support this feature. The modem must support the ADSL/ADSL2+ protocols. Boards supporting physical layer retransmission are H805ADLF, H805ADIF, H808ADLF, H808ADIF, H805ADPD, H80BCAME, and H80BADPE.
NOTE
l H805ADLF, H805ADIF, H808ADLF, and H808ADIF only support PHY-R, don't support G.INP. l The physical layer retransmission function requires the cooperation of the CPE.
l l
Boards supporting F5 OAM loopback are ADPD and ADQD. Boards supporting ADSL ATM bonding are H802ADPD, H805ADPD, H80BADPE, and H80BCAME.
NOTE
The ADSL ATM bonding function requires the cooperation of the CPE.
License Support
The number of ADSL2+ ports supported by the MA5600T/MA5603T is under license control. Therefore, the corresponding service is controlled by a license.
3.5 Principle
ADSL System Architecture
Based on provided functions, the ADSL transceiver is divided into:
3 ADSL2+ Access
l l l l
TPS-TC (convergence sub layer related to transmission protocol) PMS-TC (convergence sub layer related to physical medium) PDM (sub layer related to physical medium) MPS-TC (convergence sub layer related to management protocol for BMS interface)
Each sub layer is encapsulated and defined with the information between sub layers to perform intercommunication among different manufactures. Figure 3-1 shows the ADSL transmission architecture. Figure 3-1 ADSL transmission architecture
ATU-C OAM interface NTR C
TPS-TC TPS - #0
ATU-R MPS-TC C U R
TPS-TC TPS - #0
MPS-TC
OAM interface NTR R
I/F
User application interfaces
I/F
PMS PMS-TC TC PMS TC
PMS - TC
PMD PMD
PMD
I/F
I/F
Application specific Unspecified Main body and annexes
Application invariant
Application specific Main body and annexes Unspecified
TPS-TC TPS-TC is related to specific application. It performs the mapping of the user interface data and the control signals to and from the TPS-TC synchronization data interface. TPS-TC sends and receives control signals through the payload channel of the PMSTC layer. The MPS-TC function module provides a procedure for ADSL transceiver unit (ATU) management. The MPS-TC function module communicates with the higher level function entity of the management plane. The management messages are exchanged between the MPS-TC function entities of the ATU through the ADSL payload channel.
PMS-TC PMS-TC multiplexes of the ADSL payload and the TPS-TC data traffic. The basic functions are: framing, frame synchronization, scrambling/descrambling, forward error correction (FEC), and error check. It provides a payload channel for delivering control messages of the TPS-TC, PMS-TC and PMD layers in addition to the messages from the management interface.
l
Issue 01 (2011-10-30)
PMD
Application interfaces
TPS-TC #1
TPS-TC #1
3 ADSL2+ Access
The basic functions are: regular element generation and recovery, coding/decoding, modulation/demodulation, echo cancellation, line equalization, and link start. The PMD layer also sends and receives control messages through the payload channel of the PMS-TC
ADSL Principle
ADSL provides a total bandwidth of 1.104 MHz. By using DMT, ADSL splits the bandwidth into 256 tones (0-255). Because ADSL over POTS is different from ADSL over ISDN, the division of the 256 tones is different. Figure 3-2 shows the tones and bandwidth for ADSL over POTS. Figure 3-2 Tones and bandwidth for ADSL over POTS
POTS Upstream Downstream
32 138kHz
255 1104 kHz
4kHz 26kHz
l l l
Tones 0-5 are reserved to transmit the 4 kHz analog voice signals. Tones 6-31 are used to transmit upstream data over the bandwidth of 26-138 kHz. Tones 32-255 are used to transmit downstream data over the bandwidth of 138-1104 kHz.
Figure 3-3 shows the tones and bandwidth for ADSL over ISDN. Figure 3-3 Tones and bandwidth for ADSL over ISDN
ISDN Upstream Downstream
32 120kHz 138kHz
64 276kHz
255 1104kHz
Issue 01 (2011-10-30)
48
3 ADSL2+ Access
l l l
Tones 0-31 are reserved to transmit the 120 kHz ISDN signals. Tones 32-63 are used to transmit upstream data over the bandwidth of 138-276 kHz. Tones 64-255 are used to transmit downstream data over the bandwidth of 276-1104 kHz.
NOTE
Each tone occupies a bandwidth of 4.3125 kHz for transmission. When an ADSL terminal unit (ATU) uses echo cancellation, the ADSL signals can be transmitted in the overlapped mode, which means to extend the downstream bandwidth to the upstream bandwidth so that the upstream and downstream ADSL signals can share transmission channels.
Each ADSL tone can transmit datagram of 1-15 bits. The actual capacity of each tone depends on the real-time transmission performance such as the attenuation, delay and noise.
ADSL2+ Principle
ADSL2+ extends the bandwidth of ADSL to 2.208 MHz and uses DMT to split the bandwidth into 512 tones (0-511). Figure 3-4 shows the tones and bandwidth of ADSL2+. Figure 3-4 Tones and bandwidth of ADSL2+
When the data transmission mode is Annex A, Annex B, or Annex L, the tones are allocated as follows: l l Tones 0-5 are reserved to transmit the 4 kHz analog voice signals. Sub-carriers 6-31: Annex A/Annex L: Sub-carriers 6-31 are used to transmit the upstream data at the frequency of 26-138 kHz. Annex B: Sub-carriers 6-31 are used to transmit the upstream data at the frequency of 120-276 kHz. l l l l Tones 32-511 are used to transmit downstream data over the bandwidth of 138-2208 kHz. Tones 0-5 are reserved to transmit the 4 kHz analog voice signals. Sub-carriers 6-63 are used to transmit the upstream data at the frequency of 26 kHz-f1, where f1 ranges from 138 kHz through 276 kHz. Tones 64-511 are used to transmit downstream data over the bandwidth of 256-2208 kHz. When the data transmission mode is Annex M, the tones are allocated as follows:
ADSL2+ extends bandwidth and improves the transmission efficiency by enhancing modulation, reducing overhead and optimizing frame structure.
3 ADSL2+ Access
Physical Layer Retransmission

Emerging access services such as IPTV and video-on-demand (VoD) are winning growing popularity. These services are more sensitive to bit error ratio (BER) and packet loss ratio but less latency-strict than traditional data and voice services. Physical layer retransmission is put forward to more reliably transmit these emerging services over lines. Figure 3-5 Reference model when retransmission is enabled in both directions
TPS- TC #0 reference point DTU framer Retransmission Multiplexer Retransmission queue
reference point eoc overhead multilpexer RRC framer 12 bits A scrambler FEC(RS) interleaver L0 Latency path multilpexer reference point PMD L1 24 bits C scrambler FEC(RS) FEC ( Golay) ib NTR
This figure illustrates a reference model when retransmission is enabled in both transmit (Tx) and receive (Rx) directions, which is a typical application of physical layer retransmission. The Tx end and Rx end each have a buffer first in first out (FIFO). The Tx end classifies the data to be sent into specific data units, and the Rx end checks the data received. If detecting that a data unit is incorrect, the Rx end sends a request, asking the Tx end to retransmit this data unit. The Tx end, upon receiving this quest, retransmits this data unit stored in its buffer FIFO. In the Tx direction, there is only one activated channel, channel(#0). Data transmitted along this channel is encoded into data transmission units (DTUs). A DTU, after being sent, is stored to the retransmission queue. After a DTU is sent and no retransmission request is received, the DTU multiplexer selects a new DTU for transmission. If a retransmission request is received, the DTU multiplexer selects the desired DTU from the retransmission queue for transmission. The new DTU or DTU to be retransmitted is sent out through 2 reference point.
3 ADSL2+ Access
The physical media specific-transmission convergence (PMS-TC) layer has three channels: channel 0 (latency channel), channel 1, and retransmission request channel (RRC). Channel 0 carries only overhead data and channel 1 carries only DTUs (sent from 2 reference point). RRC carries the confirmation messages for the received DTUs. Channel 0 is encoded using ReedSolomon codes after being scrambled, while RRC is encoded using the extended Golay codes. Bit streams sent from channel 0 and RRC are combined into one channel of data frames, which is then sent to the physical medium dependent (PMD) layer through reference point.
ADSL ATM bonding

Through the ADSL ATM bonding function, one ATM packet is divided into several fragments, which will be assigned to multiple links for transmission, thus increasing the network bandwidth. Figure 3-6 shows the bonding layering of the ADSL ATM bonding. Figure 3-6 ADSL ATM bonding layering
Service GBS Cross connect
TPS-TC PMS-TC PMD BCE-1 ... BCE-32
As shown in the preceding figure, the meaning and the function of each layer is as following: l l A bonding channel entity (BCE) is a channel. The BCE here is regarded as one ADSL port because one port of the currently implemented ADSL has only one channel. Cross connect is optional. The Cross connect supplies the interface for the data transmission between the BCE and the GBS layer. It only aggregates the data of the BCE layer and transmits to the GBS layer.The data reorganization and splitting is realized by the GBS layer. The generic bonded sub-layer(GBS) reorganizes the data streams of all the bound lines and splits the downstream traffic streams. The upper layer of GBS is the service layer. In the case of the service layer, the GBS is equal to only an interface. The GBS regroups and transits the data to the service layer. The service layer then forwards ATM cells to the upper layer.
l l
The actual implementation of the ADSL ATM bonding is as following: 1. Traffic streams are set up on the GBS, but are not bound to ports. The device allows service flow configuration only on the primary port in the bonding group.
Issue 01 (2011-10-30)
51
3 ADSL2+ Access
2.
The GBS assigns the data stream to every BCE according to certain rules and therefore each BCE carries only part of the data stream. The fragments of one packet, however, must be transmitted within one BCE.
INM
The impulse noise in the x digital subscriber line (xDSL) service severely affects line stability and quality of experience (QoE). There are multiple impulse noise sources, such as household appliance switches, devices that generate electric arcs, phones' offhook and onhook state, natural discharge, and various electromagnetic waves. A frequency spectrum covers a wide region and varies with time, increasing the system bit error rate (BER) and decreasing system stability. The impulse noise protection (INP) technology adjusts noise parameters to improve line quality and minimize noise impact on lines. Before configuring INP, users need to monitor and collect statistics for current line noise distribution. The impulse noise monitor (INM) technology enables users to monitor and collect statistics of impulse noises. INM can improve service QoE that is sensitive to packet loss instead of delay. Therefore, INM is significant for widely used video services. Long-period noise detection helps carriers to better learn about the live network noise environment, facilitating QoS improvement. Figure 3-7 shows the principles for INM. Figure 3-7 Principles for INM
Indication of Severely Degraded Data Symbols Anomalies Eq INP Generation Cluster Indicator Eq INP&IAT Anomalies Generation INM Counters
INS
IAT Generation
Principles for INM are as follows: 1. An impulse noise sensor (INS) mainly detects whether discrete multi-tone (DMT) symbols are severely damaged. If yes, the INS degrades the DMT symbols. If not, the INS considers the DMT symbols normal and does not degrade them. A cluster indicator uses a specific method to identify DMT symbols detected by the INS and classifies several consecutive qualified symbols into a cluster. The cluster is used for subsequent processing. Figure 3-8 shows how to identify a cluster.
2.
Figure 3-8 Principles for INM

Cluster1 Cluster2
Gap1 INMCC = 2 Degraded symbol Undamaged symbol
Gap2
Gap3
Issue 01 (2011-10-30)
52
3 ADSL2+ Access
As shown in the preceding figure, INM cluster continuation (INMCC) specifies the maximum number of consecutive undamaged DMT symbols allowed in a cluster. In the preceding figure, INMCC is 2 and Gap1 contains two DMT symbols. Therefore, the two DMT symbols belong to the same cluster, which is identified as Cluster1. Gap2 contains three DMT symbols. Therefore, Cluster1 does not contain the DMT symbols in Gap2 and the DMT symbols following Gap2. Gap2 does not belong to any cluster. 3. The Eq INP Generation module calculates equivalent INPs (INP_eq) in each cluster. The inter arrive time (IAT) Generation module calculates the IAT of an entire symbol sequence. IAT specifies the number of symbols between the end of a cluster and the beginning of the next cluster, without Sync symbols. The Eq INP&IAT Anomalies Generation module collects statistics for INP_eq and IAT. The INM Counters module uses a rule to count the collected equivalent INP_eq and IAT and forms an irregular equivalent INP and IAT histogram based on the data. Users can view and use the data. In addition, users can configure INP_Min and Delay_Max based on equivalent INP and IAT.
4. 5.

Glossary
Table 3-1 lists the glossary of technical terms related to ADSL2+ access. Table 3-1 Glossary of technical terms related to ADSL2+ Glossary SELT Definition The single ended loop test includes: l Line type l Line length l Terminal type l Local noise l Bridge tap Tone It is the sub-carrier. For example, when the bandwidth of 1 MHz is divided into 256 sub-carriers, each carrier is called as a tone.

Table 3-2 lists the acronyms and abbreviations related to ADSL2+ access. Table 3-2 Acronyms and abbreviations related to ADSL2+ Acronym/Abbreviation ADSL POTS
Issue 01 (2011-10-30)
Full Spelling Asymmetrical Digital Subscriber Loop Plain Old Telephone Service
53
3 ADSL2+ Access
Acronym/Abbreviation ISDN CO CPE DMT MELT
Full Spelling Integrated Services Digital Network Central Office Customer Premise Equipment Discrete Multi-Tone Metallic Line Testing
Issue 01 (2011-10-30)
54
4 VDSL2 Access
4
About This Chapter
4.1 Introduction 4.2 Specifications 4.3 Reference Standards and Protocols 4.4 Availability
VDSL2 Access
Supporting the symmetric high rates of up to 100 Mbit/s, VDSL2 is a major enabler of the shortdistance and high-speed solutions for the next-generation FTTx access scenarios.
4.5 VDSL2 Architecture This topic describes the model of the VDSL2 system architecture. 4.6 Features of the VDSL2 System VDSL2 supports various features, such as high-speed transmission, long-distance transmission and flexible profile configuration solutions. 4.7 Support for Multiple Spectrum Profiles VDSL2 supports multiple spectrum profiles to fulfill the needs of different application scenarios. 4.8 Flexible PSD Control Methods VDSL2 adopts flexible power spectral density (PSD) control methods. The purposes are to protect the VDSL2 loop system against the interference from various external radio waves and at the same time mitigate the interference of VDSL2 to other transmission systems. VDSL2 implements PSD management using a series of techniques such as DPBO, UPBO, PSD notching, and MIB-controlled PSD. 4.9 Improvement of Line Performance VDSL2 improves the quality of the line system by using a series of technologies, including discrete multi-tone (DMT) modulation, trellis coding, FEC, time domain equalization, and interleaving. Some of the features are developed as defined by ITU-T Recommendation G.993.1, and some are the new features specially developed for VDSL2. 4.10 VDSL2 Network Applications This topic describes the network applications of the VDSL2 access feature.
Issue 01 (2011-10-30)
55
4 VDSL2 Access
4.1 Introduction
Definition
The VDSL technology provides subscribers with symmetric or asymmetric high-speed leased line access service over twisted pairs. The VDSL service can run at symmetric or asymmetric rates and can be provisioned over the same twisted pair with the plain old telephony service (POTS). Mainly used for the "last mile" connection, VDSL provides subscribers with voice, video, and data services in a full-service multimedia network. Very high speed digital subscriber line 2 (VDSL2) is an extension to VDSL. Compared with VDSL, VDSL2 supports a higher transmission rate and a longer transmission reach.
Purpose
VDSL2 supports the symmetric high rates of up to 100 Mbit/s and also supports multiple spectrum profiles and encapsulation modes. Thus, VDSL2 is a major enabler of the shortdistance and high-speed solutions for the next-generation FTTx access scenarios.
4.2 Specifications
The MA5600T/MA5603T supports the following VDSL2 access specifications: l l l l l l l l l l l l l l Compliance with ITU-T Recommendation G.993.2 A maximum reach distance of 3.5 km Compatibility with ADSL/ADSL2+ Support of the VDSL2/ADSL2+ compatible board, VDSL2 over POTS board, and VDSL2 over ISDN board to meet different service requirements Multiple spectrum profiles, including 8a, 8b, 8c, 8d, 12a, 12b, and 17a to meet different application scenarios Power spectral density (PSD) control through UPBO/DPBO, RFI, PSD Mask, and Tone Blackout Two encapsulation modes (ATM and PTM) Working in the ADSL/ADSL2+ mode when connecting to ADSL/ADSL2+ terminals BandPlan998 and BandPlan997 Support of 24-port, 48-port and 64-port VDSL2 boards Automatic rate adjustment according to the line conditions during the initialization Configuration, modification, and query of the VDSL2 configuration parameters (such as line and channel mode) Reporting of alarm and maintenance information about the line and the channel VDSL2 terminal management Based on the function, the VDSL2 modems can be maintained remotely through telnet, and the software of the VDSL2 modems can be remotely upgraded through TFTP. l l
Issue 01 (2011-10-30)
Configuration of the BITSWAP parameter. PPPoE+ sub option.

4 VDSL2 Access
l l l l l l l
Line template configuration change Supports configuration of three modes: TR-129 mode, TI mode, and TR-165 mode. Configuration of the ANNEX M frequency band Power-saving of the xDSL line Metallic Line Testing (MELT)(only supported by the VDJM and VDPM) Physical layer retransmission F5 OAM loopback (supported by H80BVDPM and H80BVDPE). Two-pair VDSL2 PTM bonding Support for the creation, modification and deletion of the bonding group profile. Support for the rate limitation and the rate monitoring of the bonding group.
Support for INM feature.

The reference standards and protocols of this feature are as follows: l l l l l l l ITU-T G.993.2: Very high speed digital subscriber line 2 ITU-T G.993.2 Amendment 1, ITU-T G.993.2 Amendment 2, ITU-T G.993.2 Amendment 1, nd ITU-T G.993.2 Amendment 4 ITU-T G.997.1: Physical layer management for digital subscriber line (DSL) transceivers TR-129: Protocol-Independent Management Model for Next Generation DSL Technologies TR-165: Vector of Profiles ITU-T G.998.2: Ethernet-based multi-pair bonding TR-159: Management Framework for xDSL Bonding
4.4 Availability
Hardware support
l l l l l l l The VDSA (VDSL2 over POTS) board supports 8b and 17a, and is compatible with 8a, 8c, 8d, 12a and 12b spectrum profiles. The 24-channel VDRD board supports 8c, 8d, 12a, 12b, 17a, 30a spectrum profiles. The 24-channel VDTF (VDSL2 over ISDN) board supports 8a, 8b, 8c, 8d, 12a, 12b, and 17a spectrum profiles. The 48-channel VDMF (VDSL2 over POTS) board supports 8a, 8b, 8c, 8d, 12a, 12b, and 17a spectrum profiles. The 48-channel VDNF (VDSL2 over ISDN) board supports 8a, 8b, 8c, 8d, 12a, 12b, and 17a spectrum profiles. The 48-channel VDJM (all digital mode VDSL2) board supports 8a, 8b, 8c, 8d, 12a, 12b, and 17a spectrum profiles. The 64-channel VDPE (VDSL2 over POTS) board supports 8a, 8b, 8c, 8d, 12a, 12b, and 17a spectrum profiles.
Issue 01 (2011-10-30)
4 VDSL2 Access
l l l
The 64-channel VDPM (VDSL2 over POTS) board supports 8a, 8b, 8c, 8d, 12a, 12b, and 17a spectrum profiles. The modem must support the VDSL2 protocol. Boards supporting physical layer retransmission are H805VDMF, H805VDRD, H80BVDPE, and H80BVDPM (support PHY-R and G.INP).
NOTE
The physical layer retransmission function requires the cooperation of the CPE.
l l
Boards supporting F5 OAM loopback are H80BVDPE and H80BVDPM. Boards supporting VDSL2 PTM bonding are H80BVDPE, H80BVDPM, H805VDMF, H805VDRD, and H85BVDMD. The H80BVDPE and H80BVDPM support the two-pair bonding of any two ports on a board.
NOTE
The VDSL2 PTM bonding function requires the cooperation of the CPE.
License support
The number of VDSL2 ports supported by the MA5600T/MA5603T is provided only under license. Therefore, the license is required for accessing the corresponding service.
4.5 VDSL2 Architecture

This topic describes the model of the VDSL2 system architecture.
VDSL2 Compatibility
The implementation principle of VDSL2 is based on ITU-T Recommendation G.993.2. International Telecommunication Union (ITU) defines the DMT modulation mode that is adopted by VDSL2. The VDSL2 technology is compatible with ADSL and ADSL2+. Because VDSL is not widely applied, VDSL2 is not compatible with VDSL.
VDSL2 System Architecture

The system architecture of VDSL2 is similar to that of ADSL and supports three independent application models: l l l Data service model Data service with underlying POTS service Data service with underlying ISDN service
Figure 4-1 shows the architecture of the VDSL2 transmission system.
Issue 01 (2011-10-30)
58
4 VDSL2 Access
Figure 4-1 Architecture of the VDSL2 transmission system

VTU-O gO
NTR-TC
VTU-R b IO U IR
NTR-TC
gR 8-kHz NTR
VME VME
8-kHz NTR OAM interface

User application interfaces VME
MPS-TC MPS -
MPS-TC
OAM interface
User application interfaces
PMS - TC
TPS-TC #1 TPS-TC TPS- #0
PMS - TC
I/F
TPS-TC #1 TPS-TC TPS- #0
PMD
PMD PMD
I/F
I/F
I/F
Application specific Unspecified Main body and Annexes
Application invariant Main body
Application specific Main body and Unspecified Annexes
A VDSL2 device consists of three parts: TPS-TC, PMS-TC, and PMD. l TPS-TC This module is associated with specific applications. It is mainly in charge of adapting user interface data and control signals to the synchronous data interface of the TPS-TC module. The TPS-TC layer also transmits and receives control messages through the overhead channel of the PMS-TC layer. The MPS-TC function module provides a procedure for implementing the management of the VDSL transceiver unit (VTU). The MPS-TC function module communicates with the higher-layer function entities of the management plane. The management information is exchanged between the MPS-TC function entities of the VTU through the VDSL overhead channel. l PMS-TC This module is mainly in charge of multiplexing VDSL overheads and TPS-TC data streams. The basic functions of this module include framing, frame synchronization, scrambling and descrambling, forward error correction (FEC), and error detection. The PMS-TC module provides overhead channels for transmitting the control messages of the TPS-TC, PMS-TC, and PMD layers and the messages of the management interface. l PMD The basic functions of the PMD module include regular generation and restoration of elements, encoding and decoding, modulation and demodulation, echo cancellation, linear equalization, and link start.
4 VDSL2 Access
The PMD layer also transmits and receives control messages through the overhead channel of the PMS-TC layer. The VDSL2 boards provided by the MA5600T/MA5603T implement the above-mentioned function modules in full compliance with ITU-T Recommendation G.993.2. In addition, the MA5600T/MA5603T implements the VDSL2 management module as defined by ITU-T Recommendation G.997.1 and the TR-090 standard. The VDSL2 management module provides line management functions that are configured based on line profile, channel profile, and spectrum profile, meeting the requirements of different users.
4.6 Features of the VDSL2 System

VDSL2 supports various features, such as high-speed transmission, long-distance transmission and flexible profile configuration solutions. The VDSL2 standard was included in the agenda of ITU-T in 1998 but was progressing slowly. One reason is that back then the situation of broadband access was not definite, and the ADSL technology soon met the bandwidth requirements owing to its practicality. Another reason is that the bandwidth stipulated by the VDSL standard was far higher than the bandwidth required by the market. At the same time, VDSL put much more requirements on loops than ADSL does. Owing to these reasons, VDSL was in only small-scale application in the market. In 2003, ITUT stipulated two new recommendations for ADSL, G.992.3 and G.992.5. It was then that the industry eyed VDSL more important as it provides a higher bandwidth. In October 2003, ITU-T completed the VDSL1 recommendation and meanwhile kicked off the VDSL2 project. In actual application, few products supported the VDSL1 recommendation G. 993.1. However, operators were in imperative needs for a more definite VDSL standard. Driven by such a market, ITU-T made a more specific definition of VDSL2 in G.993.2, which was rolled off in February 2006. VDSL2 supports the following features.
High-speed Transmission
VDSL2 specifies a band plan that covers the frequency as high as 30 MHz, and provides for a bidirectional high-speed data transmission at 200 Mbit/s within short distances. The 30a spectrum profile supports a total minimum upstream and downstream rates of 200 Mbit/s, and 17a supports a total of 100 Mbit/s.
Long-distance Transmission
The VDSL2 standard specifies enhanced downstream transmit power (20.5 dBm). Together with the application of frequency band US0 and techniques such as echo cancellation and time domain equalization, VDSL2 achieves a maximum transmission reach of over 2.5 km. Figure 4-2 shows the comparison between VDSL2 and ADSL/ADSL2/ADSL2+/VDSL in terms of downstream rate and distance.
Issue 01 (2011-10-30)
60
4 VDSL2 Access
Figure 4-2 Comparison between VDSL2 and ADSL/ADSL2/ADSL2+/VDSL (downstream rate and distance)
l l l
Symmetric upstream and downstream 100 Mbit/s of 6-band can be achieved only within 250 m in most cases. 5-band has a higher downstream bandwidth than 4-band only within 700 m. In terms of rate, VDSL2 is advantageous to ADSL2+ mainly within the distance of 1.2 km.
Flexible Profile Configuration Solutions

The highest frequency of VDSL2 is 30 MHz. Between 1 MHz and 12 MHz, VDSL2 still applies Band Plan 997 and Band Plan 998 of ITU-T Recommendation G.993.1. 12-30 MHz can be divided into just one or more upstream and downstream frequency bands to meet different application requirements.
Compatibility with ADSL/ADSL2+

VDSL2 adopts DMT as the only modulation mode. VDSL2 supports the PTM mode that is based on IEEE 802.3ah 64/65-byte encapsulation, and also supports the ATM encapsulation mode that is employed by ADSL/ADSL2+.
Stronger Support for Video Service

According to the characteristics of the video service, VDSL2 implements pulse noise protection by using the interleaving technique. In addition, VDSL2 can dynamically adjust the interleaving depth according to the condition of error bits. VDSL2 also specifies dual-latency channels to meet the requirements of different services (especially the video service) that have different degrees of sensitivity to packet loss and latency. Moreover, VDSL2 provides functions such as PSD control, loop diagnosis, and online reconfiguration.
4.7 Support for Multiple Spectrum Profiles

VDSL2 supports multiple spectrum profiles to fulfill the needs of different application scenarios. Owing to different network environments, the influence of different factors on communication loops may vary. Thus, it is difficult to address the application requirements of different environments by using the same mechanism. VDSL2 defines eight spectrum profiles (8a, 8b,
4 VDSL2 Access
8c, 8d, 12a, 12b, 17a, and 30a) to fulfill the needs of different application scenarios and builds a holistic mechanism to strengthen its adaptability to the environments. Figure 4-3 Spectrum profiles
Profile Bandwidth (MHz) Tones Tone Spacing (KHz) Line Power (dBm) 8a 8.832 2048 4.3125 +17.5 8b 8.832 2048 4.3125 +20.5 8c 8.5 1972 4.3125 +11.5 8d 8.832 2048 4.3125 +14.5 12a 12 2783 4.3125 +14.5 12b 12 2783 4.3125 +14.5 17a 17.664 4096 4.3125 +14.5 30a 30 3479 8.625 +14.5
VDSL2 based on DMT modulation has eight spectrum profiles. The number in a spectrum profile name represents the maximum frequency, and the letter represents the power attribute. For example, 8b and 8c mean that the maximum frequency is both 8 MHz. The maximum downstream power of the 8b spectrum profile is 20.5 dBm, and this profile is applicable to longdistance CO VDSL2 devices. The maximum downstream power of the 8c spectrum profile is 11.5 dBm, and this profile is applicable to remote outdoor cabinets running the VDSL2 service. Restricted by loop characteristics such as loop attenuation, the 30 MHz frequency band has a narrow application scope. It is mainly used for lab tests, or for loops that are in good conditions and are very short (within 300 m), where a high rate is attainable only under such conditions. Hence, the frequency band that can be used in most cases is 12 MHz or even below 8.8 MHz. VDSL2 defines different frequency band plans for different countries and areas. Figure 4-4 Band plan
VDSL2 Annex A defines the band plan for North America; Annex B defines the band plan for Europe; Annex C defines the band plan for Japan. Among the profiles, 17a has one more downstream frequency band than 12a; 30a has one more upstream frequency band than 17a. Restricted by loop characteristics such as loop attenuation, the 30 MHz frequency band has a
4 VDSL2 Access
narrow application scope. It is mainly used for lab tests, or for loops that are in good conditions and are very short (within 300 m), where a high rate is attainable only under such conditions. Hence, the frequency bands that can be used in most cases are 12 MHz or even below 8.8 MHz. The application scenarios of different VDSL2 spectrum profiles are as follows: l 17a and 30a are applicable to short distances, usually within 300 m. In fact, 30a is not widely applied and 17a is in more use. 17a provides a 100 Mbit/s downstream bandwidth and a 50 Mbit/s upstream bandwidth and applies to the FTTB+VDSL2 scenario. 12a/12b and 8c/8d are applicable to medium distances, ranging from 300 m to 1000 m, and apply to the FTTC+VDSL2 scenario. 8a and 8b have strong transmit power and are applicable to long distances. 8a and 8b are compatible with ADSL2/ADSL2+, provide a 30 Mbit/s/10 Mbit/s bandwidth, and apply to COs. 8b can provide a 20.5 dBm output power, which is equal to ADSL2+.
l l
4.8 Flexible PSD Control Methods

VDSL2 adopts flexible power spectral density (PSD) control methods. The purposes are to protect the VDSL2 loop system against the interference from various external radio waves and at the same time mitigate the interference of VDSL2 to other transmission systems. VDSL2 implements PSD management using a series of techniques such as DPBO, UPBO, PSD notching, and MIB-controlled PSD.
Downstream Power Back-off

Figure 4-5 Mitigating crosstalk using DPBO
CO PSD ADSL2+ Frequency CPE2 RT Strong signal PSD Frequency VDSL2
Crosstalk
CPE1
CO Solution DPBO
PSD ADSL2+ Frequency CPE2 RT Strong signal PSD Frequency VDSL2
No Crosstalk
CPE1
Multiple types of services may be running over the twisted pairs in the same binder at the same time, for example, symmetric or asymmetric services like POTS, ADSL, HDSL, and VDSL. The services when operating at the same time will generate interference to each other. As a result, the performance of some pairs may drop seriously. As shown in Figure 4-5, when ADSL2+ and VDSL2 services run over the twisted pairs in the same binder, VDSL2 will cause great
4 VDSL2 Access
attenuation to the low-frequency part of the ADSL2+ service. Therefore, VDSL2 defines a downstream power back-off (DPBO) mechanism to ensure that various DSL modulation technologies can work in the normal state on the twisted pairs in the same binder in most cases. Implementation mechanism of DPBO: DPBO requires the operator to test the distance between the DSLAM at the CO and the street-side DSLAM, and then apply a corresponding formula to compute the specific DPBO value. Some major operators have their own formulas.
Upstream Power Back-off

Figure 4-6 Mitigating crosstalk using UPBO
CO/RT PSD VDSL2 VDSL2 PSD Frequency Frequency
Crosstalk
CPE1
CPE2
Solution UPBO CO PSD VDSL2 VDSL2 PSD
No Crosstalk
CPE1
CPE2
To sum up, the upstream power back-off (UPBO) mechanism is to reduce the transmit power as much as possible by maintaining a given signal to noise ratio (SNR) at the receive end of the upstream channel. Figure 4-6 shows the application scenario of UPBO. The loop length (L1) of CPE1 is shorter than the loop length (L2) of CPE2 (L2 > L1). In the upstream direction, the loop of CEP1 (loop 1#) will generate serious crosstalk to the loop of CEP2 (loop 2#), causing a very low upstream rate to loop 2#. In this scenario, VDSL2 adopts the UPBO mechanism so that the upstream power of CPE1 is moderately reduced when at the same time the application requirements of loop 1# are fulfilled. Hence, loop 1# generates less crosstalk to loop 2# and the upstream transmission performance of loop 2# is improved.
PSD Notching
VDSL2 adopts a wide range of frequencies, the highest frequency being 30 MHz. The frequency spectrum covers the spectrum of medium-wave and short-wave broadcast and ham radio. Therefore, the VDSL2 technology must address the issue of radio frequency interference (RFI). The RFI implies two aspects: l l Broadcast transmission tower and ham radio launcher generate RFI to VDSL2 receivers. The VDSL2 system generates radiation that poses as RFI to radio sets and ham radio receivers.
A number of complicated factors are associated with the above-mentioned two types of interference, including transmit power, transmit frequency, distance between twisted pairs and
4 VDSL2 Access
receivers, and shielding performance of twisted pairs. Hence, it will be a highly complicated job to mitigate or reduce RFI by tackling these factors one by one. The characteristics of RFI are a very narrow interfered bandwidth and a long interference duration. The narrow-frequency characteristic means that RFI occurs mainly on one or some specific tones. Therefore, the guiding scheme of PSD notching is not to use such tones at the cost of a reduced transmission rate. In this way, the situation of reducing RFI at a high cost can be avoided. In the case of reducing the RFI generated by VDSL2 to ham radio receivers, the solution is to reduce the PSD to below -80 dBm/Hz at the transmit end of the VDSL2 system. Figure 4-7 Principle of PSD notching
TONE RFI Radio Frequency Interference
TONE
RFI
Notching
MIB-controlled PSD
DPBO, UPBO, and PSD notching are relatively fixed PSD modulation mechanisms. When it comes to complicated channels where the actual noise environment is changing in real time, such mechanisms are not flexible enough. Thus, MIB-controlled PSD is introduced. According to the distribution of DSLAMs, the distance between a DSLAM and subscribers, and the coexistence of ADSL/VDSL services, operators can shape the transmit PSD by using MIB in order to mitigate crosstalk. By using the CO MIB, a MIB-controlled PSD mask defines the PSD at a series of breakpoints that are located at the transmit frequency band. The PSD value of each sub-carrier is determined by the interpolation between two breakpoints. There are up to 16 breakpoints in the upstream direction and up to 32 breakpoints in the downstream direction. Frequency band US0 currently does not support breakpoints. The transmit breakpoint defines sub-carrier index tn and PSD mask PSDn. The CO MIB-controlled PSD mask consists of a series of transmit breakpoints, such as [(t1, PSD1) (t2, PSD2),..., (tn, PSDn)]. t1 is the start frequency point of the corresponding frequency band, and tn is the stop frequency point of the frequency band. According to the PSD values, the MIB-controlled PSD mask at different breakpoints varies: l l l l The breakpoints where PSD mask is equal to or greater than -80 dBm/Hz The breakpoints where PSD mask is smaller than -80 dBm/Hz The breakpoints where PSD mask forms an upward slope The breakpoints where PSD mask is located at the edge of a frequency band
Figure 4-8 considers the first case as an example, which is also a common case.
Issue 01 (2011-10-30)
65
4 VDSL2 Access
Figure 4-8 MIB-controlled PSD

Limit PSD mask PSD 3 PSD 2 PSD 4 MIB PSD mask
PSD 1 PSD 5
Slope = 0.75 dB/4.3125 kHZ for 4.3125 kHZ sub-carrier spacing 0.375 dB/4.3125 kHZ for 8.625 kHZ sub-carrier spacing - 80 dBm/Hz
t1(fx)
t2
t3
t4
t5(fx+1)
4.9 Improvement of Line Performance

VDSL2 improves the quality of the line system by using a series of technologies, including discrete multi-tone (DMT) modulation, trellis coding, FEC, time domain equalization, and interleaving. Some of the features are developed as defined by ITU-T Recommendation G.993.1, and some are the new features specially developed for VDSL2.
DMT Modulation
VDSL2 adopts DMT as its only modulation mode. Multi-tone modulation divides the entire transmission bandwidth into N parallel sub-channels for better use of the transmission bandwidth. Each sub-channel has a carrier, which is spectrally independent of the carriers of other sub-channels. Hence, the data rate of each sub-channel is 1/ N of the data rate of the entire transmission bandwidth. Multi-tone modulation is implemented by performing orthogonal transforming on data segments. A commonly used method is the discrete Fourier transform (DFT). The multi-tone modulation employing DFT is called DMT. The decrease of data rate will extend the cycle of the DMT symbol by N times, making the signal existence time longer than the carrier interval. Thus, it is easier to eliminate the interference between the symbols. The advantage of DMT is that it extends the transmission reach by decreasing the information transmitting rate of each twisted pair in parallel transmission. By employing the DMT technique, VDSL2 is able to perform quadrature amplitude modulation (QAM) on each sub-channel (that is, each tone). In this way, VDSL2 substantially enhances the transmission capability of each sub-channel, that is, from the originally 1-2 bits/tone to 15 bits/ tone. The high-order modulation algorithm enables VDSL2 to increase the line rate by a great extent. However, the high-order modulation algorithm puts stringent requirements on line quality, and thus also restricts the loop length of VDSL2.
Issue 01 (2011-10-30)
66
4 VDSL2 Access
Pilot Tone
In the DMT modulation mode, DMT requires strictly synchronous clocks at both ends of the system. To avoid wandering of frequency points, some pilot tones can be inserted to achieve synchronization.
Scrambling
Regular encoding (has periodic regular change, such as consecutive 0s or 1s) may have negative effects on lines. Specifically, signals thus encoded on a line may generate interference to adjacent lines and easily cause incorrect or difficult delimitation to the peer end. Therefore, signals consisting of long strings of 0s or 1s or changing regularly should be processed so that they are as random as possible before they enter a line. This is the function of scrambling. The usual method is to insert a fixed-length sequence at the local end and remove the sequence at the peer end. The sequence can keep the randomness of the signals before they enter a line.
Trellis Coding
Common channel coding techniques can be classified into convolutional coding and block coding. Trellis coding is a code modulation technique that combines convolutional coding with the digital modulation mode. The corresponding decoding technique is called Viterbi decoding. The process of trellis coding entails the redundancy of only 1 bit. Hence, trellis coding features a higher coding efficiency and a simpler coding mechanism. However, the corresponding Viterbi decoding has a complicated process. Viterbi decoding can be divided into hard decision (HD) and soft decision (SD). SD adds some probability weighted calculation to the decoding process and thus Viterbi decoding has a stronger error correcting capability. Generally, trellis coding is mainly targeted at burst errors. It can correctly parse the discrete error bits in the transmission and features strong code gaining and error correcting capabilities. Trellis coding is a mandatory technique in the VDSL2 standard.
Forward Error Correction

In general, there are multiple error correction mechanisms. Some depend on the transmission system itself to check the data and correct the errors after the data arrives at the peer end. Others only check the data and do not correct the errors; if any error is detected, the data is retransmitted. Forward error correction (FEC) belongs to the first type. FEC is applicable to real-time services because such services do not tolerate the latency that must be entailed by retransmission. All error correction mechanisms are implemented with the redundancy trade-off. So, seemingly FEC sacrifices bandwidth. However, if a line adopts the retransmission mechanism, it entails more bandwidth waste than FEC does redundancy.
Interleaving
FEC and interleaving are usually used together as a major means against pulse interference. Though FEC has a strong error correction capability, if there is serious line noise and consequently long consecutive error bits, FEC alone is helpless. This is the problem that interleaving addresses. Figure 4-9 shows an example of an interleaved block. Here, the given interleaver depth D is 3 and interleaver width I is 7. ADSL directly uses the FEC codeword NFEC as the interleaver width, whereas VDSL2 uses the fraction (I = NFEC/q) of NFEC as the interleaver width, q ranging from 1 to 8. The numbers in the block indicate the sequence at which bits enter the interleaver. Usually, bits are written to the block based on rows and read from the block based on columns.
4 VDSL2 Access
Figure 4-9 Principle of the interleaver

read (to the channel)
write (from FEC)
1 8 15
2 9 16
3 10 17
4 11 18
5 12 19
6 13 20
7 14 21
7 sequence in channel 1, 8, 15, 2, 9, 16, 3, 10, 17
Figure 4-10 shows a de-interleaver with D=3 and N=7. The output of the de-interleaver is the correct sequence of the bits. Figure 4-10 Principle of the de-interleaver
write (from channel)
read (to FEC)
1 8 15
2 9 16
3 10 17
4 11 18
5 12 19
6 13 20
7 14 21
7 sequence in channel 1, 8, 15, 2, 9, 16, 3, 10, 17
The following figure demonstrates the value of interleaving by contrasting the burst errors with interleaving and those without interleaving. The first two rows show the transmission sequence of the bits in a channel with interleaving and without interleaving. Figure 4-11 The value of interleaving by contrasting the burst errors with interleaving and those without interleaving
BITS sequence (without interleaving) BITS sequence (with interleaving) the burst errors the received BITS (without interleaving) the received BITS (de-interleaving) 1 1 2 3 4 5 6 6 7 7 8 8 9 10 11 12 13 14 15 16 10 11 12 13 14 16 1 1 2 8 3 15 4 2 5 9 6 16 7 3 8 9 10 11 12 13 14 15 16 4 11 18 5 12 19 6
10 17
Issue 01 (2011-10-30)
68
4 VDSL2 Access
Assuming burst errors as shown in row 3 occur in a channel, note the interference to the bits in the two difference cases (with interleaving and without interleaving). The last two rows of the table are the bits to be sent to the FEC block on the sample channel receiver. With interleaving enabled, the bit errors will be distributed, which means that the FEC block will have a better chance of correcting the errors. The preceding example is applicable to channels where the expected burst errors are below three bit transmission periods. Interleavers in actual application usually have D parameter and N parameter of greater values.
Optional Extension of Upstream Frequency Band US0

Compared with high-frequency bands that have more interference and are unstable, lowfrequency bands are actually valuable resources. Adopting frequency band US0 for upstream transmission effectively extends the coverage reach of VDSL2 and improves its upstream performance. VDSL2 can not only enable frequency band US0 for upstream transmission but also extend the originally reserved US0 frequency band. The original frequency band US0 is 25-138 kHz, which can be extended to 276 kHz. Actually, considering the requirements for upstream bandwidth, VDSL2 increases the bandwidth of US0 by trading off some DS1 bandwidth.
Physical Layer Retransmission

Emerging access services such as IPTV and video-on-demand (VoD) are winning growing popularity. These services are more sensitive to bit error ratio (BER) and packet loss ratio but less latency-strict than traditional data and voice services. Physical layer retransmission is put forward to more reliably transmit these emerging services over lines.
Issue 01 (2011-10-30)
69
4 VDSL2 Access
Figure 4-12 Reference model when retransmission is enabled in both directions

TPS- TC #0 reference point DTU framer Retransmission Multiplexer Retransmission queue
reference point eoc overhead multilpexer RRC framer 12 bits A scrambler FEC(RS) interleaver L0 Latency path multilpexer reference point PMD L1 24 bits C scrambler FEC(RS) FEC ( Golay) ib NTR
This figure illustrates a reference model when retransmission is enabled in both transmit (Tx) and receive (Rx) directions, which is a typical application of physical layer retransmission. The Tx end and Rx end each have a buffer first in first out (FIFO). The Tx end classifies the data to be sent into specific data units, and the Rx end checks the data received. If detecting that a data unit is incorrect, the Rx end sends a request, asking the Tx end to retransmit this data unit. The Tx end, upon receiving this quest, retransmits this data unit stored in its buffer FIFO. In the Tx direction, there is only one activated channel, channel(#0). Data transmitted along this channel is encoded into data transmission units (DTUs). A DTU, after being sent, is stored to the retransmission queue. After a DTU is sent and no retransmission request is received, the DTU multiplexer selects a new DTU for transmission. If a retransmission request is received, the DTU multiplexer selects the desired DTU from the retransmission queue for transmission. The new DTU or DTU to be retransmitted is sent out through 2 reference point. The physical media specific-transmission convergence (PMS-TC) layer has three channels: channel 0 (latency channel), channel 1, and retransmission request channel (RRC). Channel 0 carries only overhead data and channel 1 carries only DTUs (sent from 2 reference point). RRC carries the confirmation messages for the received DTUs. Channel 0 is encoded using ReedSolomon codes after being scrambled, while RRC is encoded using the extended Golay codes. Bit streams sent from channel 0 and RRC are combined into one channel of data frames, which is then sent to the physical medium dependent (PMD) layer through reference point.
4 VDSL2 Access
VDSL2 PTM bonding

Through the VDSL2 PTM bonding function, one Ethernet packet is divided into several fragments, which will be assigned to multiple links for transmission, thus increasing the network bandwidth. Fragmentation of an Ethernet packet and assignment of fragments are implemented by the 802.3ah protocol. In the case of bonding based on the VDSL2 access, the negotiation for the VDSL2 PTM bonding features between the CO and CPE through G.994.1 is required. Figure 4-13 shows the bonding layering of the VDSL2 PTM bonding. Figure 4-13 VDSL2 PTM bonding layering
Service GBS Cross connect
TPS-TC PMS-TC PMD BCE-1 ... BCE-32
As shown in the preceding figure, the meaning and the function of each layer is as following: l l A bonding channel entity (BCE) is a channel. The BCE here is regarded as one VDSL2 port because one port of the currently implemented VDSL2 has only one channel. Cross connect is optional. The Cross connect supplies the interface for the data transmission between the BCE and the GBS layer. It only aggregates the data of the BCE layer and transmits to the GBS layer.The data reorganization and splitting is realized by the GBS layer. The generic bonded sub-layer(GBS) reorganizes the data streams of all the bound lines and splits the downstream traffic streams. The upper layer of GBS is the service layer. In the case of the service layer, the GBS is equal to only an interface. The GBS regroups and transits the data to the service layer. The service layer then forwards Ethernet packets to the upper layer.
l l
The actual implementation of the VDSL2 PTM bonding is as following: 1. 2. Traffic streams are set up on the GBS, but are not bound to ports. The device allows service flow configuration only on the primary port in the bonding group. The GBS assigns the data stream to every BCE according to certain rules and therefore each BCE carries only part of the data stream. The fragments of one packet, however, must be transmitted within one BCE.
Issue 01 (2011-10-30)
71
4 VDSL2 Access
INM
The impulse noise in the x digital subscriber line (xDSL) service severely affects line stability and quality of experience (QoE). There are multiple impulse noise sources, such as household appliance switches, devices that generate electric arcs, phones' offhook and onhook state, natural discharge, and various electromagnetic waves. A frequency spectrum covers a wide region and varies with time, increasing the system bit error rate (BER) and decreasing system stability. The impulse noise protection (INP) technology adjusts noise parameters to improve line quality and minimize noise impact on lines. Before configuring INP, users need to monitor and collect statistics for current line noise distribution. The impulse noise monitor (INM) technology enables users to monitor and collect statistics of impulse noises. INM can improve service QoE that is sensitive to packet loss instead of delay. Therefore, INM is significant for widely used video services. Long-period noise detection helps carriers to better learn about the live network noise environment, facilitating QoS improvement. Figure 4-14 shows the principles for INM. Figure 4-14 Principles for INM
Indication of Severely Degraded Data Symbols Anomalies Eq INP Generation Cluster Indicator Eq INP&IAT Anomalies Generation INM Counters
INS
IAT Generation
Principles for INM are as follows: 1. An impulse noise sensor (INS) mainly detects whether discrete multi-tone (DMT) symbols are severely damaged. If yes, the INS degrades the DMT symbols. If not, the INS considers the DMT symbols normal and does not degrade them. A cluster indicator uses a specific method to identify DMT symbols detected by the INS and classifies several consecutive qualified symbols into a cluster. The cluster is used for subsequent processing. Figure 4-15 shows how to identify a cluster.
2.
Figure 4-15 Principles for INM

Cluster1 Cluster2
Gap1 INMCC = 2 Degraded symbol Undamaged symbol
Gap2
Gap3
As shown in the preceding figure, INM cluster continuation (INMCC) specifies the maximum number of consecutive undamaged DMT symbols allowed in a cluster. In the preceding figure, INMCC is 2 and Gap1 contains two DMT symbols. Therefore, the two DMT symbols belong to the same cluster, which is identified as Cluster1. Gap2 contains
4 VDSL2 Access
three DMT symbols. Therefore, Cluster1 does not contain the DMT symbols in Gap2 and the DMT symbols following Gap2. Gap2 does not belong to any cluster. 3. The Eq INP Generation module calculates equivalent INPs (INP_eq) in each cluster. The inter arrive time (IAT) Generation module calculates the IAT of an entire symbol sequence. IAT specifies the number of symbols between the end of a cluster and the beginning of the next cluster, without Sync symbols. The Eq INP&IAT Anomalies Generation module collects statistics for INP_eq and IAT. The INM Counters module uses a rule to count the collected equivalent INP_eq and IAT and forms an irregular equivalent INP and IAT histogram based on the data. Users can view and use the data. In addition, users can configure INP_Min and Delay_Max based on equivalent INP and IAT.
4. 5.
4.10 VDSL2 Network Applications

This topic describes the network applications of the VDSL2 access feature. Figure 4-16 VDSL2 network applications
Copper Access
IPTV Server splitter
PC ADSL/ADSL2+ CPE PC VDSL2 CPE splitter
MA5600T/MA5603T
PON FTTx+xDSL Access ADSL/ADSL2+ CPE PC VDSL2 CPE PC PSTN Voice Stream
ONU
As shown in Figure 4-16, VDSL2 in actual application applies to two typical scenarios. 1. The MA5600T/MA5603T directly provides the VDSL2 access. On the user side, ADSL/ADSL2+ CPEs (working in the ATM mode) or VDSL2 CPEs (working in the PTM mode) can be connected to the MA5600T/MA5603T to provide highspeed Internet access service and video service for subscribers.
4 VDSL2 Access
2.
The MA5600T/MA5603T provides PON optical ports for connecting to ONUs and the ONUs provide the VDSL2 access. The ONUs are placed on street side or in corridors. In the downstream direction, the ONUs provide the VDSL2 access for subscribers; in the upstream direction, the ONUs are connected to the MA5600T/MA5603T by PON. The FTTx+VDSL2 network topology addresses the distance restriction on the VDSL2 access.
Issue 01 (2011-10-30)
74
5 SHDSL Access
5
About This Chapter
SHDSL Access
SHDSL is an xDSL access technology, just like ADSL and VDSL. SHDSL provides the symmetric upstream and downstream rates. 5.1 ATM SHDSL Access This topic describes the definition, purpose, specifications, and limitations of ATM SHDSL access feature. It also provides the glossary and the acronyms and abbreviations related to the ATM SHDSL access feature. 5.2 EFM SHDSL Access This topic describes the definition, purpose, specifications, and limitations of EFM SHDSL access feature. It also provides the glossary and the acronyms and abbreviations related to the EFM SHDSL access feature. 5.3 TDM SHDSL Feature
Issue 01 (2011-10-30)
75
5 SHDSL Access
5.1 ATM SHDSL Access

This topic describes the definition, purpose, specifications, and limitations of ATM SHDSL access feature. It also provides the glossary and the acronyms and abbreviations related to the ATM SHDSL access feature.
5.1.1 Introduction
Definition
SHDSL is an xDSL access technology, just like ADSL and VDSL. SHDSL provides the symmetric upstream and downstream rates. The symmetric upstream and downstream rates of ATM SHDSL determine that bi-directional rates of the supported service must be basically the same. In addition, ATM SHDSL features a longer transmission distance. Hence, ATM SHDSL can be widely used.
Purpose
ATM SHDSL provides symmetric broadband access services for subscribers to meet the requirement for high downstream rate from SOHO subscribers. ATM SHDSL applications are similar to ADSL applications and the ATM SHDSL and ADSL applications are mutually complementary.
The specifications of SHLB and SHLM are as follows: l l l These boards support the single-pair and two-pair modes. Network timing reference (NTR) clock. Automatic rate adjustment according to the line conditions during initialization.
NOTE
For the two, three, or four bound ATM ports, the system does not support automatic rate adjustment.
l l l l l l l l l l l
Reporting of the alarms and maintenance information of lines. PPPoE+ sub option. Dynamic adjustment of the specifications of the SHDSL line profile and alarm profile. Power-saving of the xDSL line. Supports wetting current. A maximum transmission distance of 6 km. Supports the configuration, modification, and query of the SHDSL line profile. Four modes of binding EFM or ATM ports: single-pair (two-wire), two-pair (four-wire), three-pair (six-wire), and four-pair (eight-wire). Line rate ranging from 192 kbit/s to 5696 kbit/s in the single-pair mode. Supports crosstalk cancellation. The line rate of the bound two, three, or four ATM/EFM ports is double, triple, or quadruple the line rate of a single port.
Issue 01 (2011-10-30)

NOTE
5 SHDSL Access
l Each port in an EFM bonding group can be activated or deactivated independently. Hence, in a specific application, the line rate of the bonding group varies according to the number of the activated ports in the group. l As defined in IEEE 802.3ah, the ratio of the maximum rate to the minimum rate in an EFM bonding group cannot exceed 4. For example, if the minimum rate is 192 kbps, the maximum rate cannot exceed 768 kbps.
l l
Supports F5 OAM loopback. Supports the configuration of ATM/EFM mode based on port.
The specifications that are supported only by the SHLM are as follows: l l Supports IMA bonding of G.SHDSL. Supports MELT function.
5.1.3 Availability
Hardware Support
The SHLB board supports 16 channels of ATM and PTM SHDSL service. The SHLM board with MELT function supports 16 channels of G.SHDSL.BIS service.
License Support
The port rate measurement function and cross talk cancellation supported by the MA5600T/ MA5603T is under license. Therefore, the corresponding service is also under license.
5.1.4 Reference
The following lists the reference documents of this feature: l l ITU-T Recommendation G.991.2 Annex A and Annex F. ITU-T Recommendation G.991.2 Annex B and Annex G.
5.1.5 Principle
Typical Application Model
The SHDSL operating principle is based on the G.991.2 (2001) standard. Figure 5-1 Typical application model of SHDSL
S/T User Terminal S/T User Terminal STU-R U-R DLL U-C SRU U-R U-C U-R U-C DLL STU-C V
DLL
CO Netw ork
. . .
Optional
Optional T1541150-00 (114701)
Issue 01 (2011-10-30)
. . .
77
5 SHDSL Access
One SHDSL system consists of an STU-C, an STU-R, and a subscriber terminal. Multiple repeaters can be added to the line between the STU-C and the STU-R. l l l The STU-C provides service ports at the central office. The STU-R provides subscriber ports for connecting to multiple subscriber terminals. The SHDSL repeater unit (SRU) refers to the repeater. In ultra-long distance transmission, it recovers signals and re-transmits signals to increase the transmission distance.
The MA5600T/MA5603T does not support repeaters.
Terminal Model
The SHDSL terminal model consists of the following parts: l PDM module The PDM module implements functions such as: Regular code element generation and recovery, coding/decoding, modulation/demodulation, echo control, linear equalization, and link start SHDSL mainly uses the trellis coded pulse amplitude modulation (TC-PAM) technology. l PMS-TC module The PMS-TC module implements functions such as: framing, frame synchronization scrambling, and descrambling l TPS-TC module The TPS-TC module implements functions such as: mapping and encapsulation of data frames, multiplexing and demultiplexing, timing alignment of multiple subscriber data channels l I/F interface of the device at the central office It mainly provides the ATM port. The ATM port is used for transmitting ATM cells over the ATM network, or according to the carried packets, transmitting Ethernet packets encapsulated by the SAR module or E1/V3.5 signals over the Ethernet network. l I/F interface of the device on the subscriber side It corresponds to the I/F interface of the device at the central office. In general, the I/F interface is used for providing Ethernet ports or E1/V.35 ports. When the MA5600T/MA5603T uses the SHLB board, the TC-PAM encoding technology is shown as the following table. Table 5-1 TC-PAM encoding technology Compliant Standards SHDSL Describes... R = n64 + (i)8, 3 n 36 and 0 i 7 (192 kbit/s to 2312 kbit/s)
The SHLB board of the MA5600T/MA5603T is based on ATM. The board provides the Ethernet port (for broadband access) or E1/V.35 port (for private line access) for connecting subscriber
5 SHDSL Access
terminals. In the upstream direction, the board is connected to the metropolitan area network (MAN) through the upstream board.
5.1.6 Acronyms and Abbreviations

Table 5-2 Acronyms and abbreviations of the ATM SHDSL access feature Acronym/Abbreviation SHDSL HDSL TC-PAM ATM Wet current Full Spelling Single-line high speed digital subscriber line High-speed digital subscriber line Trellis coded pulse amplitude modulation Asynchronous transfer mode 3-5 mA DC current provided for the subscriber line. (The purpose is to heat up the subscriber line to remove the gas such as steam attached to the surface of the subscriber line, thereby effectively preventing the subscriber line from corrosion and oxidation. In this way, the overall electric performance of the subscriber line is protected.)
5.2 EFM SHDSL Access

This topic describes the definition, purpose, specifications, and limitations of EFM SHDSL access feature. It also provides the glossary and the acronyms and abbreviations related to the EFM SHDSL access feature.
5.2.1 Introduction
Definition
SHDSL is an xDSL access technology, just like ADSL and VDSL. SHDSL provides the symmetric upstream and downstream rates. EFM SHDSL integrates the advantages of the SHDSL technology and the ADSL technology. That is, EFM SHDSL can provide traditional voice service and high rate Internet access service over common twisted pairs to meet the requirements for high definition TV service and VoD service from subscribers, which suit the last mile access for broadband to the campus.
Purpose
The utilization ratio of the EFM access service is high when the activation rates of the ATM and EFM access services are the same. Hence, if the subscriber terminal supports ATM and EFM SHDSL access services simultaneously, the EFM SHDSL access service is preferred.
5 SHDSL Access
The specifications of SHLB and SHLM are as follows: l l l These boards support the single-pair and two-pair modes. Network timing reference (NTR) clock. Automatic rate adjustment according to the line conditions during initialization.
NOTE
For the two, three, or four bound ATM ports, the system does not support automatic rate adjustment.
l l l l l l l l l l l
Reporting of the alarms and maintenance information of lines. PPPoE+ sub option. Dynamic adjustment of the specifications of the SHDSL line profile and alarm profile. Power-saving of the xDSL line. Supports wetting current. A maximum transmission distance of 6 km. Supports the configuration, modification, and query of the SHDSL line profile. Four modes of binding EFM or ATM ports: single-pair (two-wire), two-pair (four-wire), three-pair (six-wire), and four-pair (eight-wire). Line rate ranging from 192 kbit/s to 5696 kbit/s in the single-pair mode. Supports crosstalk cancellation. The line rate of the bound two, three, or four ATM/EFM ports is double, triple, or quadruple the line rate of a single port.
NOTE
l Each port in an EFM bonding group can be activated or deactivated independently. Hence, in a specific application, the line rate of the bonding group varies according to the number of the activated ports in the group. l As defined in IEEE 802.3ah, the ratio of the maximum rate to the minimum rate in an EFM bonding group cannot exceed 4. For example, if the minimum rate is 192 kbps, the maximum rate cannot exceed 768 kbps.
l l
Supports F5 OAM loopback. Supports the configuration of ATM/EFM mode based on port.
The specifications that are supported only by the SHLM are as follows: l l Supports IMA bonding of G.SHDSL. Supports MELT function.
5.2.3 Availability
Hardware Support
The SHLB board supports 16 channels of ATM and PTM SHDSL service. The SHLM board with MELT function supports 16 channels of G.SHDSL.BIS service.
License Support
The port rate measurement function and cross talk cancellation supported by the MA5600T/ MA5603T is under license. Therefore, the corresponding service is also under license.
5 SHDSL Access
5.2.4 Reference
The following lists the reference documents of this feature: l l ITU-T Recommendation G.991.2 Annex A and Annex F. ITU-T Recommendation G.991.2 Annex B and Annex G.
5.2.5 Principle
Typical Application Model
The SHDSL operating principle is based on the G.991.2 (2001) standard. Figure 5-2 Typical application model of SHDSL
S/T User Terminal S/T User Terminal STU-R U-R DLL U-C SRU U-R U-C U-R U-C DLL STU-C V
DLL
CO Netw ork
. . .
Optional
Optional T1541150-00 (114701)
One SHDSL system consists of an STU-C, an STU-R, and a subscriber terminal. Multiple repeaters can be added to the line between the STU-C and the STU-R. l l l The STU-C provides service ports at the central office. The STU-R provides subscriber ports for connecting to multiple subscriber terminals. The SHDSL repeater unit (SRU) refers to the repeater. In ultra-long-distance transmission, it recovers signals and re-transmits signals to extend the transmission distance.
The MA5600T/MA5603T does not support repeaters.
Terminal Model
The SHDSL terminal model consists of the following parts: l PDM module The PDM module implements functions such as: Regular code element generation and recovery, coding/decoding, modulation/demodulation, echo control, linear equalization, and link start SHDSL mainly uses the trellis coded pulse amplitude modulation (TC-PAM) technology. l PMS-TC module The PMS-TC module implements functions such as: framing, frame synchronization scrambling, and descrambling l
Issue 01 (2011-10-30)
TPS-TC module
. . .
5 SHDSL Access
The TPS-TC module implements functions such as: mapping and encapsulation of data frames, multiplexing and demultiplexing, timing alignment of multiple subscriber data channels l I/F interface of the device at the central office Providing ATM ports or circuit interfaces The ATM port is used for transmitting ATM cells over the ATM network, or according to the carried packets, transmitting Ethernet packets encapsulated by the SAR module or E1/V3.5 signals over the Ethernet network or E1 links. The circuit interface is used for transmitting E1 or V.35 signals directly through the time division multiplexing (TDM) network. l I/F interface of the device on the subscriber side It corresponds to the I/F interface of the device at the central office. In general, the I/F interface is used for providing Ethernet ports (for delivering ATM cells processed by the SAR module) or E1/V.35 ports. Table 5-3 TC-PAM encoding technology Compliant Standards SHDSL Describes... R = n64 + (i)8, 3 n 89 and 0 i 7 (192 kbit/s to 5696 kbit/s)
Typical Networking Application

The following figure shows the typical networking application of EFM SHDSL. Figure 5-3 Typical networking application of EFM SHDSL
FE/GE
MA5600T/MA5603T
ATM SHDSL Modem
EFM SHDSL Modem
PC_A
Issue 01 (2011-10-30)
PC_B
82
5 SHDSL Access
5.2.6 Glossary, Acronyms, and Abbreviations

Glossary
None
Acronym and Abbreviations

Table 5-4 Acronyms and abbreviations of the EFM SHDSL access feature Acronym/Abbreviation EFM SHDSL HDSL Wet current Full Spelling Ethernet in the first mile Single-line high speed digital subscriber line High-speed digital subscriber line 3-5 mA DC current provided for the subscriber line. (The purpose is to heat up the subscriber line to remove the gas such as steam attached to the surface of the subscriber line, thereby effectively preventing the subscriber line from corrosion and oxidation. In this way, the overall electric performance of the subscriber line is protected.)
5.3 TDM SHDSL Feature

5.3.1 Introduction
Definition
Single-pair high-speed digital subscriber line (SHDSL), defined by ITU-T (such as ITU-T G. 991.2), is a data transmission technology over twisted pairs to transmit voice, data, and video signals. TDM SHDSL is a mode to transmit TDM signals through SHDSL. As the transmission mode varies, the device provides different types of upstream ports. Specifically, the TDM-E1-G.703 electrical port is used by the device for the TDM transmission system; the ATM-STM-1 optical port is used by the device for the ATM transmission system. Similarly, the user-side CPE also provides different types of data ports to adapt to different transmission modes. Specifically, for the TDM transmission system, the CPE generally provides the TDM-V.35 or E1-G.703 port; for the ATM transmission system, the CPE generally provides the ATM-FR-V.35, 10/100Base-T Ethernet, or ATM-CE-V.35 (or E1-G.703) port.
Purpose
TDM SHDSL provides the TDM-V.35 or E1-G.703 port. Compared with the V.35 and E1 cables, SHDSL has an advantage of farther transmission distance; therefore, SHDSL can extend the reach of DDN nodes over abundant twisted pair resources.
5 SHDSL Access
TDM SHDSL achieves E1 transmission and access over subscriber cables at "last two miles" and at the same time carries various services of N x 64 kbit/s. Hence, TDM SHDSL makes possible the broadband private line access for users over the existing transmission network resources.
Benefit
The abundant twisted pair resources can be utilized to achieve the long-distance access of the circuit emulation equipment with the E1 or V.35 port, thereby reducing the consumption of copper wire resources.
The specifications of the TDM SHDSL feature are as follows: SHDSL plane: l l l Data path mode: ATM, PTM, TDM Rate: N x 64 kbit/s (3 N 32) Frame structure: E1, V35
TDM SHDSL port plane: l l l l l l l l l Supports 16 SHDSL ports per EDTB board. Clock source: system clock and line clock Supports 2-wire and 4-wire modes. Supports access of the PRA service through SHDSL. Supports the configuring of the signaling mode and frame format: CCS and UNFRAME. Supports CRC4: enable/disable. Supports loopback on an SHDSL port (loopback mode: local loopback and remote loopback). Supports power backoff on an SHDSL port. Supports the reporting of alarms and maintenance information about lines.
NOTE
TDM SHDSL generally provides a 2-wire port. When the transmission distance exceeds 6 km, the 4-wire port is required. A 4-wire port is implemented by bundling two 2-wire ports.
E1 port plane: l l l l l l l Supports 16 E1 ports per EDTB board. Clock source: system clock and line clock Supports the configuring of the signaling mode and frame format: CCS and UNFRAME. Supports CRC4: enable/disable. Supports the configuring of the line impedance (75 ohms or 120 ohms) on the E1 port. Supports loopback on an E1 port (loopback mode: local loopback and remote loopback). Supports the reporting of alarms and maintenance information about lines.
Public plane: l
Issue 01 (2011-10-30)
Configures the working mode of EDTB: VOICE mode or SAToP mode.

5 SHDSL Access
l l l
Configures the running mode of VOICE: service mode and transparent transmission mode. Supports PRA services (including H.248- and SIP-compliant) and IP semipermanent connections (SPCs) in service mode. Supports a maximum of 512 (number of B channels) concurrent online PRA users.
Device capability: l l l Supports a maximum of 64 ports corresponding 2 H802EDTB boards in service mode. Supports a maximum of 8 H802EDTB boards in transparent transmission mode. Supports a maximum of 256 ports corresponding 8 H802EDTB boards in SAToP mode.

The reference standards and protocols of the TDM SHDSL feature are as follows: l l G.991.2 Annex A and Annex F: Standards applicable for North America ITU-T G.991.2 Annex B and Annex G: Standards applicable for European
5.3.4 Availability
Relevant NE
The TDM SHDSL modem must support the TDM SHDSL protocol.
License Support
The TDM SHDSL feature is provided without a license.
Version Support
Table 5-5 Version support Product MA5600T/MA5603T Version V800R008 and later versions
Hardware Support
Currently, the board supporting the TDM SHDSL feature is H802EDTB.
NOTE
If the PRA service is required, the H802EDTB board must be installed with a voice daughter board. If the IP SPC service is required, the H802EDTB board must be installed with a voice daughter board. The TDM SHDSL modem must support the TDM SHDSL protocol. If the multi-pair mode is required, the terminal must support the multi-pair mode of the same port.
Limitations
The H802EDTB board can work only in the VOICE mode .
5 SHDSL Access
When working in the VOICE mode, the H802EDTB can be further configured with the service mode and the transparent transmission mode. l l In the case of the transparent transmission mode, only transparent transmission is allowed and the PRA or SPC service cannot be configured. In the case of the service mode, transparent transmission is not allowed and the PRA and SPC services can be configured.
When the clock source of the H802EDTB board is configured to line clock, ports with UNFRAME configuration cannot be selected as the clock source. When working in the transparent transmission mode, the H802EDTB board need not be configured with the clock source.
5.3.5 Principle
Basic Principle
Based on the G.991.2 (2001) standard, the SHDSL system consists of an SHDSL transceiver unit at the Central Office (STU-C), an SHDSL transceiver unit at the Remote End (STU-R), and a user terminal. Between STU-C and STU-R, there may be several SHDSL regenerator units (SRUs), as shown in Figure 5-4. Figure 5-4 Typical application model of SHDSL
S/T User terminal U-R U-C S/T User terminal Optional Optional STU-R SRU
...
U-R
U-C STU-C
V CO network
SRU: SHDSL Regenerator Unit STU-C: STU at the Central Office
STU: SHDSL Transceiver Unit STU-R: STU at the Remote End
l l l
The STU-C provides the service ports on the CO side. The STU-R provides the user ports. One STU-R can be connected to multiple user terminals. SRUs are used in ultra-distance transmission and it recovers signals and re-transmits signals to increase the transmission distance.
STU-Cs are generally placed in a centralized manner and provide network-side upstream ports to form the DSLAM equipment. According to the varying transmission mode in the system, the DSLAM provides different upstream ports.
5 SHDSL Access
l l
In the case of the TDM transmission system, the DSLAM generally provides the TDM-E1G.703 electrical port. In the case of the ATM transmission system, the DSLAM generally provides the ATMSTM-1 optical port.
The STU-R and user-side data port form the user-side CPE. Similarly, the CPE provides different user-side ports to meet the requirements of the varying transmission modes. l l In the case of the TDM transmission system, the CPE generally provides the TDM-V.35 or E1-G.703 port. In the case of the ADM transmission system, the CPE generally provides the ATM-FR-V. 35, 10/100Base-T Ethernet port, or ATM-CE-V.35 (or E1-G.703) port.
NOTE
In the case of the TDM transmission system, the MA5600T/MA5603T supports only the TDM-E1-G.703 electrical port for upstream transmission and only TDM SHDSL (E1) on the user side. In the case of the ATM transmission system, because the IP network is a mainstream network, the MA5600T/ MA5603T does not support the ATM-STM-1 optical port for upstream transmission but the MA5600T/ MA5603T supports ATM access.
Working Mode
The H802EDTB board can work in the VOICE mode. In the case of TDM SHDSL in the VOICE mode, the H802EDTB board needs to be configured with the working sub-mode: service mode or transparent transmission mode. l Service mode Each G.SHDSL port and E1 port are independent ports, on which the SPC, PRA service, port rate, or port mode can be configured. l Transparent transmission mode The H802EDTB board automatically connects the Nth SHDSL line with the Nth E1 line to transparently transmit the 2M data. The E1 port is in the UNFRAME format. The clock locks the Nth E1 line clock. Therefore, every E1 line has its independent clock. In the transparent transmission mode, the SPC and PRA services cannot be configured.
5.3.6 Narrowband Data Private Line Service Applications

The narrowband data private line service is mainly demonstrated in expanding the reach of DDN nodes. TDM SHDSL for expanding the reach of DDN nodes is a mainstream method supported by the integrated access equipment to provide the DDN service. On the CO side, the integrated access equipment connects to the DDN node through E1; on the user side, the TDM-capable SHDSL modem provides the TDM SHDSL (E1) port to implement N x 64 kbit/s private line access and at the same time achieves private line interconnection by supporting the V.35-capable router, as shown in Figure 5-5.
Issue 01 (2011-10-30)
87
5 SHDSL Access
Figure 5-5 Narrowband data private line service applications

Router FE V.35 SHDSL modem TDM SHDSL (E1) E1 SHDSL modem V.35 TDM SHDSL (E1) MA5600T/ MA5603T
Router FE
The MA5600T/MA5603T connects to the DDN node in the following two ways: l l Transparent transmission Aggregation
Figure 5-6 shows how the MA5600T/MA5603T connects to the DDN node in the transparent transmission mode: The H802EDTB board connects upstream to the DDN network through E1 and connects downstream to the SHDSL modem through SHDSL. Figure 5-6 Connection to the DDN (in the transparent transmission mode)
E1 H802 EDTB E1 Port E1 E1 ... E1
SHDSL Port
SHDSL
SHDSL
...
SHDSL
SHDSL SHDSL modem Router
The working sub-mode of the H802EDTB board of the MA5600T/MA5603T is set to the transparent transmission mode. In this mode, the H802EDTB board automatically maps E1 ports 0-15 to SHDSL ports 16-31 to transparently transmit data.
NOTE
In addition, the clock source for every E1 port on the H802EDTB board comes from the E1 line clock and the clock source for an SDHSL port keeps synchronized with its corresponding E1 port.
Issue 01 (2011-10-30)
88
5 SHDSL Access
Figure 5-7 shows how the MA5600T/MA5603T connects to the DDN node in the aggregation mode: The H802EDTB connects upstream to the DDN network through E1 and connects downstream to the SHDSL modem through SHDSL. Figure 5-7 Connection to the DDN (in the aggregation mode)
E1 H802 EDTB E1 Port TS0 TS1 ... TSn N*64K SHDSL Port ... 64K ... 32*64K SHDSL SHDSL modem N*64K Router M*64K 64K 64K ... ... TSm ... TS 31 M*64K 64K 32*64K SHDSL ...
An SHDSL port supports only framed N x 64 kbit/s, that is, the SHDSL modem still sends 32 x 64 kbit/s to the equipment (certain timeslots of the 32 timeslots may not carry data because N may be smaller than 32). In this way, The H802EDTB board aggregates certain timeslots in 32 x 64 kbit/s for multiple SHDSL ports and then sends them upstream to the DDN.
NOTE
That is, N x 64 kbit/s is input to the SHDSL modem and the modem outputs E1 frames with 32 timeslots. The equipment aggregates certain timeslots of multiple E1 frames into a same E1 port and then sends them upstream to the DDN.
The working sub-mode of the H802EDTB board of the MA5600T/MA5603T is set to the service mode. In addition, the frame format of the E1 and SHDSL ports are configured to UNFRAME, and SPCs are set up for timeslots between N x 64 kbit/s for multiple SHDSL ports and E1 ports. This achieves the aggregation of multiple N x 64 kbit/s into E1, that is, timeslot channels of different lines are multiplexed to the same E1 upstream port, thereby saving E1 resources.
5.3.7 PRA Carrying Applications

Figure 5-8 shows the long-distance access of the PBX to the IP network for carrying the PRA service.
Issue 01 (2011-10-30)
89
5 SHDSL Access
Figure 5-8 PRA carrying applications

PBX TDM SHDSL modem MA5600T/ MA5603T
Softswitch/IMS E1/ PRA TDM SHDSL
E1
TG
H.248/SIP RTP
l l
The PBX provides E1 in the upstream direction. The SHDSL modem implements the E1-to-SHDSL conversion and connects upstream through SHDSL to the SHDSL port on the H802EDTB board of the MA5600T/ MA5603T. The MA5600T/MA5603T connects upstream to the IP network. The working mode of the H802EDTB board of the MA5600T/MA5603T is configured to the service mode. The signaling mode of the SHDSL port is configured to CCS. In addition, the D channel signaling of the PRA is transmitted in timeslot 16 and timeslot 0 is used for frame synchronization.
l l l
By using SHDSL, the MA5600T/MA5603T provides long-distance transmission to implement long-distance access of the MA5600T/MA5603T and PBX.

Glossary
Glossary Port binding Explanation Port binding is to bind two or more ports as one port for use, thereby increasing bandwidth. A timeslot represents a communication channel and is allocated to one user. (Time is segmented into periodical non-overlapped frames and every frame is further segmented into several non-overlapped timeslots.)
Timeslot
Issue 01 (2011-10-30)
90
5 SHDSL Access
Glossary Common channel signaling
Explanation Common channel signaling (CCS) is a method of transmitting a group of voice signaling over the public data link in the form of messages, where the signaling channel and the service channel are completely separate. China's No. 7 signaling system is a CCS system. Channel associated signaling (CAS) is a method of transmitting signaling over the corresponding voice channels. China's No. 1 signaling system is a CAS system.
Channel associated signaling
Acronym and Abbreviation

Acronym and Abbreviation CAS CCS CPE TDM DDN PBX SPC PRA SAToP Full Spelling Channel associated signaling Common channel signaling Customer premises equipment Time division multiplexing Digital data network Private branch exchange Semipermanent connection Primary rate access Structure-agnostic transport over packet
Issue 01 (2011-10-30)
91
6 ATM Access
6
About This Chapter
6.1 Introduction 6.2 Specifications 6.3 Reference Standards and Protocols 6.4 Availability 6.5 Principle
ATM Access
This topic describes the definition, purpose, specifications, reference standards and protocols, availability, and principle of the ATM access feature.
Issue 01 (2011-10-30)
92
6 ATM Access
6.1 Introduction
Definition
The ATM access is a feature by which the MA5600T/MA5603T provides ATM ports to subtend the traditional ATM DSLAMs in the current network.
Purpose
Currently, the IP MAN, instead of the ATM network, is mainly used. Original ATM networks gradually evolve to IP MANs. In the evolution from ATM networks to IP networks, carriers are gradually replacing ATM devices with IP devices. In the current network, however, there are still a large number of ATM devices, which are distributed at the ATM access layer and the ATM backbone layer. To protect the investment and the network stability of carriers, the MA5600T, a new generation IP-core DSLAM, provides ATM ports to subtend the traditional ATM DSLAMs.
Glossary
Table 6-1 Glossary of the ATM access feature Glossary PWE3 Explanation Pseudo wire emulation edge-to-edge (PWE3) is an end-to-end technology for bearing Layer 2 services. It is a point-to-point L2VPN.

Table 6-2 Acronyms and abbreviations of the ATM access feature Acronym/Abbreviation ATM CAR PWE3 PVC PVP VP Full Spelling Asynchronous Transfer Mode Committed Access Rate Pseudo wire Emulation Edge-to-Edge Permanent Virtual Channel Permanent Virtual Path Virtual Path
Issue 01 (2011-10-30)
93
6 ATM Access
6.2 Specifications
Specifications
l l l l l l l PVC switching PPPoE+ and DHCP option 82 QinQ VLAN and VLAN stacking Upstream transmission through a smart VLAN or MUX VLAN CAR (at a granularity of 64 kbit/s) for the downstream direction of the PVC Up to four STM-1 ports on each AIUG board Upstream transmission mode: upstream transmission through GE ports
Limitations
l l l l VP switching is not supported. Configuring PVP is not supported. The CES or FR service (that has high requirements for clock) on the subtended ATM DSLAMs is not supported. The multicast service on the subtended ATM DSLAMs is not supported. The single-PVC for multiple services on the subtended ATM DSLAMs is not supported.

The following lists the reference standards and protocols of this feature: l l ITU-T I.363.5, AAL5 Service Adaptation Protocol ITU-T I.361, B-ISDN ATM layer specification
6.4 Availability
License Support
The ATM access feature is an optional feature of the MA5600T/MA5603T, and the corresponding service is controlled by a license.
Version Support
Table 6-3 Version Support Product MA5600T/ MA5603T Version V800R004 and later
Issue 01 (2011-10-30)
94
6 ATM Access
Hardware Support
The AIUG board (ATM unit interface board) supports the ATM access feature. Each AIUG board provides two slots for housing daughter boards, and provides one to four 155 Mbit/s ATM optical ports through the O2CS optical daughter board. The O2CS optical daughter board is an STM-1 single-mode optical daughter board. The optical fiber must match the type of the optical port. That is, only single-mode optical fibers can be connected to the single-mode optical ports. The following table describes the names and functions of the daughter boards supported by the AIUG board. Daughter Board O2CS Description Two single-mode STM-1 optical ports (can be used as the UNI); a maximum transmission distance of 30 km Maximum Number of Daughter Boards on AIUG 2
The AIUG board provides a maximum bandwidth of 300 Mbit/s. The bandwidth assigned to each port, however, depends on the port quantity and port type. The following lists the default values configured during initialization. l l When the AIUG board provides two optical ports, the bandwidth allocated to each port is 155 Mbit/s and the total bandwidth is 300 Mbit/s. When the AIUG board provides four optical ports, the bandwidth allocated to each port is 75 Mbit/s and the total bandwidth is 300 Mbit/s.
6.5 Principle
Clock Feature of the AIUG Board
The AIUG board supports two modes of Tx clock: the system clock and the line clock. The line-side clock of the AIUG board can be used as the clock source of the clock daughter board of the control board. At the same time, the system clock can be used as the line Tx clock of the AIUG board. When the control board does not have a clock daughter board, the system clock can be used as the line-side clock of the AIUG board.
ATM Access/Upstream Transmission Through Ethernet Ports

In the case of the ATM access, the upstream transmission through Ethernet ports is supported. The most common function of an ATM port is to convert the ATM cells from the ATM DSLAM into Ethernet packets, and then to send the Ethernet packets to the upper-layer Ethernet MAN through the upstream interface of the IP DSLAM. Figure 6-1 illustrates the principle of ATM access/upstream transmission through Ethernet ports.
Issue 01 (2011-10-30)
95
6 ATM Access
Figure 6-1 Principles of ATM access/upstream transmission through Ethernet ports
ATM BRAS
ATM PWE3
GE/ FE MA5600T/ MA5603T STM-1 ATM DSLAM
ADSL2+
Modem Modem
Upstream direction (from the ATM DSLAM to the IP DSLAM) 1. 2. 3. 4. Restore the ATM frames from the ATM DSLAM to ATM cells. Assemble ATM cells to ALL5 frames. Restore AAL5 frames to Ethernet frames. Add the corresponding VLAN tag in the Ethernet frame header and send the Ethernet frame to the Ethernet MAN through the upstream interface. The IP DSLAM receives Ethernet packets from the Ethernet MAN and encapsulates them to AAL5 frames. The IP DSLAM segments AAL5 frames as single cells. The IP DSLAM encapsulates cells to the frames of the corresponding ATM interface (for example, an STM-1 port) and sends the frames to the ATM DSLAM through the ATM interface (for example, an STM-1 port).
Downstream direction (from the IP DSLAM to the ATM DSLAM) 1. 2. 3.
Issue 01 (2011-10-30)
96
7 MPLS
7
About This Chapter
7.1 Overview 7.2 Reference Standards and Protocols 7.3 Availability
MPLS
Multiprotocol Label Switching (MPLS) was introduced to improve the forwarding speed. However, because of its excellent performance in traffic engineering (TE) and virtual private network (VPN), which are the two critical technologies, MPLS is becoming an important standard for extending the IP network.
7.4 MPLS Multiprotocol Label Switching (MPLS) was introduced to improve the forwarding speed. However, because of its excellent performance in traffic engineering (TE) and virtual private network (VPN), which are the two critical technologies, MPLS is becoming an important standard for extending the IP network. This topic provides the introduction, availability, principle, and reference of the MPLS feature. 7.5 MPLS RSVP-TE MPLS RSVP-TE is a technology which integrates TE and the MPLS superimposed model. It provides high quality of service (QoS) and TE capability for users by establishing LSPs based on TE. This topic provides introduction to this feature and describes the principle and reference documents of this feature. 7.6 MPLS OAM MPLS OAM checks if an LSP is in the normal state through a mechanism, and reports the alarm information if the LSP fails. This topic provides introduction to this feature and describes the principle and reference documents of this feature. 7.7 Glossary, Acronyms, and Abbreviations This topic provides the glossary, acronyms, and abbreviations of the MPLS feature.
Issue 01 (2011-10-30)
97
7 MPLS
7.1 Overview
Multi-protocol Label Switching (MPLS) is between the data link layer and the network layer in the TCP/IP protocol stack. The label in a short fixed length is used to encapsulate IP packets. On the data plane, fast label forwarding is implemented. On the control plane, MPLS can meet the requirements on the network from various new applications with the help of the powerful and flexible routing functions of the IP network. The MPLS feature includes the following sub features: l Basic MPLS functions Basic MPLS functions provide a basis for other MPLS sub features. MPLS, which is not restricted by any specific link layer protocol, can use any Layer 2 medium to transmit network packets. This shows that MPLS is not a service or application, but a tunnel technology. This technology can both support multiple higher-layer protocols and services, and ensure the security of information transmission to a certain extent. l MPLS RSVP-TE To deploy engineered traffic on a large-scale backbone network, a simple solution with good expansibility must be adopted. MPLS, as a stacking model, can easily establish a virtual topology over a physical network and map traffic to this topology. Therefore, a technology that integrates MPLS with traffic engineering, namely, MPLS-TE is generated. l MPLS OAM MPLS, as the key bearer technology for the extensible network-generation network, provides multiple services with QoS guarantee. In addition, MPLS introduces a unique network layer and therefore the faults caused by this new network layer may occur. Therefore, an MPLS network must have the OAM capability. The MPLS feature supports the following functions: l l l l l Functioning as a P device Capability of 100 pps for processing LDP and RSVP packets when functioning as a P device MPLS label switching Penultimate hop popping (PHP) Query of LSP packet statistics by label

The following lists the reference standards and protocols of this feature: 1. PWE3 l RFC3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture l RFC4447: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) l RFC3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) l RFC4446: IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) l RFC4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks
7 MPLS
l RFC4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks l RFC5085: Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires l RFC4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) l RFC5462: Multiprotocol Label Switching (MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class Field l RFC4385: Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN l draft-ietf-pwe3-redundancy-bit-00 2. RSVP l RFC2205: Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification l RFC3209: RSVP-TE: Extensions to RSVP for LSP Tunnels l RFC2210: The Use of RSVP with IETF Integrated Services l RFC2961: RSVP Refresh Overhead Reduction Extensions l RFC3270: Multi-Protocol Label Switching (MPLS) Support of Differentiated Services l RFC4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels 3. LDP l RFC3031: Multiprotocol Label Switching Architecture l RFC5036: LDP Specification l RFC3215: LDP State Machine l RFC3478: Graceful Restart Mechanism for Label Distribution Protocol l RFC3815: Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) 4. MPLS l draft-ietf-mpls-lsp-ping-version-06 l RFC4379: Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures l RFC3032: MPLS Label Stack Encoding l RFC3469: Framework for Multi-Protocol Label Switching (MPLS)-based Recovery l RFC3812: Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) l RFC3813: Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) l RFC3814: Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) l Y.1710: Requirements for OAM functionality for MPLS networks l Y.1711: OAM mechanisms for MPLS networks l Y.1720: Protection switching for MPLS networks
Issue 01 (2011-10-30)
99
7 MPLS
7.3 Availability
License Support
The MPLS feature is an optional feature, and the corresponding service is controlled by the license.
Version Support
Table 7-1 Version Support Product MA5600T/ MA5603T Version V800R062 and later (exclude V800R009C00)
Feature Dependency
l l l l l l l l l l l l The MA5600T/MA5603T cannot support the Layer 3 VPN. One subrack supports up to two SPUB boards. It is recommended that you insert these two boards into two adjacent parity slots and set them to work in the active-standby mode. The CR-LDP is not supported. Auto TE FRR is not supported. FDI is not supported. OAM for the external LSP that is set up by the LDP is not supported. The reverse channel of MPLS OAM must be a dedicated LSP but cannot be a shared LSP or non-MPLS channel. Facility Backup is supported, but one-to-one backup protection is not supported. The MA5600T/MA5603T can function as the label switching router (LSR). The load sharing among LDP LSPs is supported. The MA5600T/MA5603T can function as the P node on the network. VCCV detecting for the PW is supported.
Hardware Support
The cooperation from the SPUB board is required.
7.4 MPLS
Multiprotocol Label Switching (MPLS) was introduced to improve the forwarding speed. However, because of its excellent performance in traffic engineering (TE) and virtual private network (VPN), which are the two critical technologies, MPLS is becoming an important standard for extending the IP network. This topic provides the introduction, availability, principle, and reference of the MPLS feature.
Issue 01 (2011-10-30)
100
7 MPLS
7.4.1 Introduction
Definition
Basic MPLS features mainly refer to the MPLS Label Distribution Protocol (LDP) and LSP management function. The LDP protocol is a standard MPLS label distribution protocol defined by the IETF. LDP, which is mainly used to allocate labels for the negotiation between LSRs to set up label switching paths (LSPs), regulates various types of information for the label distribution process, and the related processing. The LSRs form an LSP that crosses the entire MPLS domain according to the local forwarding table, which correlates in the label, network hop node, and out label of each specific FEC. With the LSP management function, the MA5600T/MA5603T can manage and maintain the LSPs generated by various LDPs and can issue the hardware forwarding module.
Purpose
MPLS is initially put forth to improve the forwarding speed of routers. Compared with the traditional IP routing mode, during data forwarding, MPLS analyzes the IP packet header only on the edge of the network, but does not analyzes the IP packet header at each hop. This saves the processing time. With the development of the ASIC technology, the route search speed is not a bottleneck for network development. Thus, MPLS has not obvious advantages in forwarding speed. MPLS, however, is widely applied to the virtual private network (VPN), traffic engineering, and quality of service (QoS) due to its characteristics of supporting multi-layer labels and connected-oriented forwarding plane. Therefore, MPLS becomes an increasingly important standard for expanding the scale of the IP network.
MPLS can use multiple LDPs, including the following protocols: l l The protocols dedicated for label distribution, such as LDP and constraint-based routing using LDP (CR-LDP) The extended label distribution protocols based on existing protocols, such as Border Gateway Protocol (BGP) and Resource Reservation Protocol (RSVP)
The MA5600T/MA5603T supports the LDP and RSVP protocols and manual configuration of the static LSP. The MA5600T/MA5603T does not support the CR-LDP protocol and the BGP label distribution protocol.
NOTE
The MA5600T/MA5603T cannot use the BGP protocol to distribute labels; however, the MA5600T/ MA5603T supports the BGP routing protocol.
l l l l
Issue 01 (2011-10-30)
Downstream unsolicited (DU) label distribution and downstream-on-demand (DoD) label distribution LDP inter-domain extension function Ordered label control mode Liberal label retention mode
7 MPLS
l l l l l l l l
Penultimate hop popping function, and implicit and explicit NULL labels Functioning as the LER and the transit LSR 1024 LDP LSPs 256 static LSPs 32 LDP local peers 530 LDP remote peers LDP graceful restart (GR) function Value range of labels: In label of the static LSP: 8192-9343 In label of the static PW: 8192-9343 Label distributed through LDPl: 10240-16383 Label distributed through RSVP: 10240-16383 Label distributed through L2VPN: 10240-16383
SPUB supporting a total of 10G switching capacity in upstream and downstream directions when the system work in the active/standby mode: 5G for each of upstream and downstream when traffic exists in both directions 10G for upstream or downstream when traffic exists only in one direction
SPUB supporting a total of 20G switching capacity in upstream and downstream directions when the system work in the load-sharing mode: 10G for each of upstream and downstream when traffic exists in both directions 20G for upstream or downstream when traffic exists only in one direction
Active-standby working mode of the MPLS service processing board
7.4.3 Principle
Multiprotocol label switching (MPLS) was introduced to improve the forwarding speed. However, because of its superb performance in traffic engineering (TE) and virtual private network (VPN), which are the two critical technologies in the current IP network, MPLS has become an important standard for extending the IP network. IP technologies are connectionless at both the forwarding plane and control plane while ATM technologies are connection-oriented at the two planes. The MPLS technology combines the advantages of IP and ATM technologies and achieves a connectionless control plane and a connection-oriented forwarding plane. Such a combination provides for flexible IP routing and convenient Layer 2 switching as well as expanded ATM service variety. Figure 7-1 shows the MPLS packet format. Figure 7-1 MPLS packet format
Label
TC
TTL
Layer 2 header
MPLS header
IP header
Data
Issue 01 (2011-10-30)
102
7 MPLS
l l l l
Label: a 20-bit label value field, used as the forwarding pointer. TC: short for traffic class, a 3-bit field for QoS (note that this field was named EXP and is renamed TC in RFC5462). S: a 1-bit bottom of stack field. This bit set to 1 indicates the bottom label in the label stack. TTL: short for time to live, an 8-bit field, similar to the TTL field in an IP header.
Basic MPLS Concepts

l Forwarding equivalence class (FEC) An FEC refers to a group of data streams which are forwarded in the same manner. These data streams are forwarded by the LSR in the same manner. Theoretically, FECs can be classified according to the IP address, service type, or QoS. For example, in the conventional IP forwarding by using the maximum matching algorithm, all the packets to the same route belong to an FEC. Currently, FECs are generally classified based on the address. The MA5600T/MA5603T supports only address-based FECs. l Label A label is a short fixed length physically contiguous identifier which is used to identify an FEC, usually of local significance. In certain conditions, for example, when load sharing is required, one FEC may map multiple labels. On one device, however, one label can represent only one FEC. Label encapsulation is performed between the link layer and the network layer. Therefore, label can be supported by any link layer. l Penultimate hop popping On the last hop node, the label no longer has any function. In this case, the label stack may be popped at the penultimate LSR of the LSP, rather than at the LSP Egress, to reduce the load of the last hop LSR. The last hop LSR directly forwards IP packets or next-layer labels, which are configured at the egress by the PHP. l Label switching router (LSR) An LSR, also called an MPLS node, is a network device which is capable of exchanging and forwarding MPLS labels. LSRs are the basic elements in an MPLS network. All LSRs support the MPLS protocol. l Label edge router (LER) An LSR on the edge of the MPLS domain is called the LER. If an LSR has a neighbor node that does not run the MPLS protocol, the LSR is an LER. The LER is responsible for classifying the packets that enter the MPLS domain to FECs and adding labels to these FECs for forwarding in the MPLS domain. When the packets leave the MPLS domain, the FECs pop up the labels, resume the original packets, and then are forwarded accordingly. l Label switched path (LSP) The path that a packet in a particular FEC traverses in an MPLS network is called the LSP. The LSP, similar to the ATM virtual circuit in function, is a unidirectional path from the ingress to the egress. l Label distribution protocol (LDP) LDP, also called the signaling protocol, is the MPLS control protocol. LDP is responsible for series of operations such as FEC classification, label distribution, and LSP establishment and maintenance. MPLS can use multiple label distribution protocols, such as the Label Distribution Protocol (LDP) and Resource Reservation Protocol Traffic Engineering (RSVP-TE).
7 MPLS
LDP is a standard MPLS label distribution protocol defined by the IETF. LDP is responsible for FEC classification, label distribution, and LSP establishment and maintenance. RSVP-TE is an extension to RSVP and provides high QoS and TE capability for users by establishing TE LSPs. l Label distribution mode In an MPLS system, the downstream LSR determines the label to be advertised to a specific FEC, and then notifies the upstream LSR. That is, the label is specified by the downstream LSR, and is advertised from the downstream LSR to the upstream LSR. The label advertisement modes on the upstream and downstream LSRs with label advertisement adjacencies must be the same. Otherwise, the LSP cannot be set up. The two label advertisement modes are as follows: Downstream unsolicited (DU) mode In the DU mode, the LSR allocates labels to a specific FEC without asking for the label request message from upstream LSRs. Downstream on demand mode In the DoD mode, the LSR allocates labels to a specific FEC only after obtaining the label request message from upstream LSRs.
NOTE
When a downstream LSR feeds back the label mapping information is determined by the label control mode used by the LSR. l When an LSR supports the ordered label control mode, it sends the label mapping information to the upstream LSR only when it receives the label mapping message returned by the downstream LSR, or when it is the egress node of the FEC. l When an LSR supports the independent label distribution control mode, it sends the label mapping message to the upstream LSR regardless of whether it receives the label mapping message returned by the downstream LSR.
Label distribution control mode The label distribution control mode is the mode used by the LSR to allocate labels during the establishment of LSPs. The two label distribution control modes are as follows: Independent label distribution control mode In the independent label distribution control mode, the local LSR can independently allocate a label to an FEC and binds the label to the FEC, and notify the upstream LSR of the label, without waiting for the label from the upstream LSR. Ordered label control mode In the ordered label control mode, the LSR can send the label mapping message of an FEC to the upstream LSR only when the LSR has the label mapping message of the next hop of the FEC, or when the LSR is the egress node of the FEC.
Label retention mode The label retention mode is the mode adopted by the LSR to process the received label mapping messages that are not in use temporarily. The two label retention modes are as follows: Liberal retention mode If an LSR supports the liberal retention mode, it maintains the label mapping received from the neighbor LSR regardless of whether the neighbor LSR is its own next hop.
Issue 01 (2011-10-30)
104
7 MPLS
When the next hop neighbor changes due to the change of network topology, the LSR that supports the liberal retention mode can use the label sent from the non-next-hop neighbor to set up LSPs quickly. This, however, requires more memory and label space. Conservative retention mode If an LSR supports the conservative retention mode, it maintains the label mapping received from the neighbor LSR only when the neighbor LSR is its next hop. When the next hop neighbor changes due to the change of network topology, the LSR that supports the conservative retention mode can save memory and label space because the LSR maintains only the label from the next hop neighbor. The re-establishment of LSPs, however, lasts a long time. Figure 7-2 shows the protocol stack model for label distribution. Figure 7-2 Protocol stack model for label distribution
Label 300 LER LSR
Label 200 LSR
Label 100 LER
IP ETH
IP ETH
IP ETH
IP ETH
IP ETH
IP ETH
IP ETH LSP(100) VLAN ETH
IP ETH xDS L
xDS L LSP(300 ) VLAN ETH
LSP(300) LSP(200) VLAN ETH VLAN ETH
LSP(200) LSP(100) VLAN ETH VLAN ETH
LER: Push Label Or POP Label
LSR: Switch Label
LSR: Switch Label
LER: Push Label Or POP Label
Working principle of the MPLS feature

Figure 7-3 shows the working principle of the MPLS feature Figure 7-3 MPLS network structure
MA5600T/ MA5603T MA5600T/ MA5603T
Label Switched Path (LSP) Ingress
Egress MPLS core LSR MPLS Edge Router (LER)
Issue 01 (2011-10-30)
105
7 MPLS
1. 2. 3. 4.
First, enable MPLS and LDP on each router on the network, and enable LDP on the interconnected interfaces. Consequently, LDP automatically sets up an LDP session between any two routers. The LDP packets are carried on this session. LDP works with the traditional routing protocol such as OSPF and RIP to set LSPs in each LSR for the FEC with service requirements. LDP does not need to be enabled for the establishment of static LSPs. Configure the FEC, and inbound and outbound labels on each MPLS router that the static LSP travels.
MPLS Active and Standby Protection

The MA5600T/MA5603T implements active and standby protection for the MPLS service through the active and standby MPLS service boards (SPUBs). Figure 7-4 shows the working principle of active and standby protection for the MPLS service. Figure 7-4 Working principle of active and standby protection for the MPLS service
Active control board A B Active SPUB
Service board
G Standby control board
H Standby SPUB
The user-side MPLS data is transmitted to the SPUB board for processing through the control board, and then transmitted to the upstream network through the control board again after being processed by the SPUB board.
Port B of the two internal 10GE ports on the active SPUB board is connected to port A on the active control board. Ports A and B are used to receive and transmit the network-side and userside packets. The other port (port F) is connected to port E on the standby control board. Port D of the two internal 10GE ports on the standby SPUB board is connected to port C on the active control board. Ports C and D are used to receive and transmit the network-side and userside packets. The other port (port H) is connected to port G on the standby control board. Therefore, after the active and standby SPUB boards form a protection group, the system automatically switches the MPLS services to the standby SPUB board when the active SPUB board fails, thereby implementing active and standby protection for the MPLS services.
LDP GR
The GR is a key technology for implementing the high availability (HA). The GR protocol collects the information about the protocol control plane from neighbors or remote peers but
7 MPLS
does not learn about the information about the control plane through the handshake and exchange of the protocol. The LDP GR function ensures normal forwarding of the MPLS service during the active/standby switchover or upgrade of the system. In addition, the LDP GR function resumes the LDP session and completes the LSP establishment after the active/standby switchover or upgrade of the system
NOTE
In actual application, to prevent services from being affected by the active control board failure, configure the system-level GR in the environment where both active and standby control boards are configured.
LDP Extension for Inter-Area LSP

Figure 7-5 Networking topology of LDP Extension for Inter-Area LSP
Loopback0 1.3.0.1/32
Loopback0 1.1.0.1/32 POS1/0/0 10.1.1.1/24 LSRA IS-IS Area20
0/1 Loopback0 S1/ /24 /0 LSRB 1 O 1/0 /24 1.2.0.1/32 P .1.1. S 2 20 PO 1.1. . IS-IS 20 PO Area10 20 S1 .1. /0/ POS1/0/0 2.1 2 10.1.1.2/24 LSRD /24 Loopback0 1.3.0.2/32 P 20 OS1 .1. /0/ 2.2 0 /24 LSRC
As shown in Figure 7-5, there are two IGP areas, Area 10 and Area 20. In the routing table of LSRD at the edge of Area 10, there are two host routes to LSRB and LSRC. Generally, to prevent a large number of routes from occupying too many resources, on LSRD, you can use IS-IS to aggregate the two routes to one route 1.3.0.0/24 and send this route to Area 20. Consequently, there is only one aggregated route (1.3.0.0/24) but not 32-bit host routes in the routing table of LSRA. By default, when establishing LSPs, LDP searches the routing table for the route that exactly matches the forwarding equivalence class (FEC) in the received Label Mapping message. Table 7-2 shows routing entry information of LSRA and routing information carried in FEC in the situation as shown in Figure 7-5.
Issue 01 (2011-10-30)
107
7 MPLS
Table 7-2 Routing entry information of LSRA and routing information carried in FEC Routing entry information of LSRA 1.3.0.0/24 FEC 1.3.0.1/32 1.3.0.2/32
LDP establishes liberal LSPs rather than inter-area LDP LSPs for aggregated routes. In this situation, LDP cannot provide required backbone network tunnels for VPN services. Therefore, in the situation as shown in Figure 7-5, you need to configure LDP to search for routes according to the longest match rule to establish LSPs. There is already an aggregated route 1.3.0.0/24 in the routing table of LSRA. When LSRA receives a Label Mapping message (such as the carried FEC is 1.3.0.1/32) from Area 10, LSRA searches for a route according to the longest match rule defined in RFC 5283. Then, LSRA finds information about the aggregated route 1.3.0.0/24, and uses the outbound interface and next hop of this route as those of the route 1.3.0.1/32. In this manner, LDP can establish inter-area LDP LSPs.
7.5 MPLS RSVP-TE

MPLS RSVP-TE is a technology which integrates TE and the MPLS superimposed model. It provides high quality of service (QoS) and TE capability for users by establishing LSPs based on TE. This topic provides introduction to this feature and describes the principle and reference documents of this feature.
7.5.1 Introduction
Definition
MPLS RSVP-TE is a technology that integrates TE with the MPLS technology. MPLS RSVPTE establishes label switched path (LSP) tunnels along specified paths for resource reservation, enables network traffic to avoid the node where congestion occurs to balance network traffic. To establish constraint-based LSPs in MPLS TE, RSVP is extended. The extended RSVP signaling protocol is called the RSVP-TE signaling protocol.
Purpose
To deploy engineered traffic on a large-scale backbone network, a simple solution with good expansibility must be adopted. MPLS, as a stacking model, can easily establish a virtual topology over a physical network and map traffic to this topology. MPLS TE establishes the LSP tunnel along a specified path through RSVP-TE and reserves resources. Thus, carriers can accurately control the path that traffic traverses to avoid the node where congestion occurs. This solves the problem that certain paths are overloaded and other paths are idle, utilizing the current bandwidth resources sufficiently. At the same time, MPLS TE can reserve resources during the establishment of LSP tunnels to ensure the QoS. To ensure continuity of services, MPLS TE also introduces route backup to implement quick switching in case of link failure.
7 MPLS
l l l l l l l l l The RSVP-TE protocol Opaque Type 10 LSA (OSPF TE extension) The CSPF protocol Strict and loose explicit paths Active and standby TE LSPs Functioning as the ingress or egress LER on an MPLS RSVP-TE network 64 ingress TE LSPs 64 egress TE LSPs GR function for RSVP TE
7.5.3 Principle
Basic MPLS RSVP-TE Concepts
l CR-LSP An LSP that is established based on certain constraints is called a constraint-based routed label switched path (CR-LSP). Different from a common LSP, the establishment of a CRLSP depends on the routing information. In addition, some conditions must be met, for example, the specified bandwidth, the fixed route, and QoS parameters. CR-LSPs can be classified into the following two categories: Static CR-LSP The forwarding information and resources information about a static CR-LSP are configured manually and the signaling protocol and route calculation are not involved. Less resource is occupied because the MPLS control packets do not need to be exchanged. The static CR-LSP, however, is seldom applied because it cannot dynamically adjust according to the topology change of the network. Dynamic CR-LSP A dynamic CR-LSP is established and maintained through the signaling mechanism, and route calculation is required. l RSVP Resource Reservation Protocol (RSVP) is designed for the integrated service model and is used to reserve resources on each node on a path. RSVP works on the transmission layer, but does not participate in the transmission of application data. RSVP, similar to ICMP, is a network control protocol. l RSVP-TE To establish the CR-LSP, RSVP is extended. The extended RSVP signaling protocol is called the RSVP-TE signaling protocol. l Explicit route A CR-LSP that is established along a specified path is called an explicit route. The two types of explicit route are as follows: Strict explicit route On a strict explicit route, the next hop node must be directly connected to its preceding hop node. The route of the LSP can be precisely controlled by using the strict explicit route.
7 MPLS
Loose explicit route The path between a loose node and its preceding node MAY include other network nodes that are not part of the strict node or its preceding abstract node.
NOTE
The MPLS TE signaling can carry the strict or loose attributes of an explicit path, and establish a CR-LSP along a specified path.
Composition of MPLS RSVP-TE

The following four components are necessary to the MPLS TE function: l Information advertisement component In addition to the topology information about the network, TE also needs to know the load information about the network. Therefore, MPLS TE introduces the information advertisement component, that is, MPLS TE maintains the link attribute and topology attribute of the network on each node through IGP extensions to form the TE database (TEDB). The path that meets all types of constraints can be calculated by using the TEDB. The extended OSPF protocol adds certain TE-related attributes such as link bandwidth and color to the link connection status, where the maximum reservable bandwidth and unreserved bandwidth for the link with each priority are the most important. l Route selection component After the information advertisement component forms the TEDB, the path that the LSP tunnel passes can be specified on each ingress node. This explicit path can be a strict or loose explicit path. In addition, the restraints such as the bandwidth can be specified. The route selection component calculates the path that meets the specified constraints by using the data in the TEDB through the constraint shortest path first (CSPF) algorithm. l Signaling component After the shortest path from the ingress to the egress of the LSP is obtained, the TE tunnel, which is used to forward the traffic that enters the ingress of the LSP, needs to be established. This process is implemented by the signaling component. The MA5600T/MA5603T supports establishment of LSP tunnels through RSVP. The RSVP signaling can carry the constraint parameters such as the bandwidth of the LSP, certain explicit routes, and color. An LSP can also be established without the signaling protocol. That is, an LSP can be established through allocating labels manually hop by hop. An LSP established in this mode is called a static CR-LSP. l Packet forwarding component The packet forwarding component of MPLS RSVP-TE is based on the label, that is, it forwards packets along the existing LSPs through labels. The defects of the IGP routing protocol can be avoided because the path of an LSP tunnel can be specified.
Process of TE LSP Tunnel Establishment

The LSP established through RSVP-TE has the resource reservation capability, and certain resources of the LSR on the LSP can be allocated to the LSP. Thus, the services transmitted on the LSP can be guaranteed. Figure 7-6 shows the process of TE LSP tunnel establishment.
Issue 01 (2011-10-30)
110
7 MPLS
Figure 7-6 Process of TE LSP tunnel establishment
Ingress Router Path Resv Sender Path Resv
Egress
Receiver
The process of TE LSP tunnel establishment is summarized as follows: 1. 2. The ingress LSR generates the Path message and transmits it to the egress LSR. After the egress LSR receives the Path message, the egress LSR generates the Resv message and transmits it to the ingress LSR. At the same time, the LSRs on the LSP reserves resources for the LSP through the Resv message. When the ingress LSR receives the Resv message, it indicates that the LSP is successfully established.
3.
RSVP-TE GR
RSVP-TE graceful restart (GR) is a status recovery mechanism of RSVP-TE. When the control plane performs active/standby switchover, RSVP-TE GR can ensure the continuity of data transmission on the forwarding plane. At the same time, neighbor nodes help the GR node to recover in time. RSVP-TE GR is based on the Hello mechanism of RSVP. The recovery of the local status depends on the upstream Path message or the downstream Recovery Path message. RSVP GR has the following features: Shortening the information recovery of the control plane; reducing changes of temporary routes; ensuring the continuity of service forwarding on the forwarding plane.
7.6 MPLS OAM

MPLS OAM checks if an LSP is in the normal state through a mechanism, and reports the alarm information if the LSP fails. This topic provides introduction to this feature and describes the principle and reference documents of this feature.
7.6.1 Introduction
Definition
Operation Administration & Maintenance (OAM) has the following features: l l l
Issue 01 (2011-10-30)
Simplifying network operations Checking the network performance anytime Reducing OPEX of the network
7 MPLS
Deployment of an effective OAM mechanism is crucial to the running of the network, especially to the network with certain QoS requirements, namely, certain performance and usability requirements. MPLS, as the key bearer technology for the extensible network generation network, provides multiple services with QoS guarantee. In addition, MPLS introduces a unique network layer and therefore there will be faults that are only relevant to this new network layer. Therefore, an MPLS network must have the OAM capability. MPLS OAM provides both detection tools and mature protection switching mechanisms. In this way, MPLS can perform switching when a fault occurs on the MPLS layer. This minimizes the loss of user data.
Purpose
The MPLS OAM functions are as follows: l l Fault detection: Requirement-based query and continuous detection are provided to learn about anytime whether faults exist on the monitored LSP. Protection switching: After a fault occurs, it can be detected, analyzed, and located, and an alarm will be reported. In addition, the corresponding measures can be taken according to the fault type.
l l l l l l l OAM and protection switching for static tunnels and dynamic tunnels (dynamic tunnels are set up through the RSVP-TE signaling) 1:1 LSP protection mode 32 LSP protection groups Transmission and processing of the CV, FFD, and BDI packets in MPLS OAM Transmitting CV packets at an interval of 1s Transmitting FFD packets at an interval of 10 ms, 20 ms, 50 ms, 100 ms, 200 ms, or 500 ms Transmitting BDI packets at an interval of 1s
7.6.3 Principle
Background Knowledge for MPLS OAM
1. MPLS OAM packets are classified as follows: l Connectivity detection (CD) packets. The two types of CD packets are as follows: Connectivity verification (CV) Fast failure detection (FFD) l Forward defect indication (FDI) l Backward defect indication (BDI) MPLS OAM is implemented by periodically transmitting detection packets CV or FFD over the detected LSPs. 2. Basic detection process MPLS OAM is implemented by periodically transmitting detection packets CV and FFD over the detected LSPs.
7 MPLS
l To detect the source by using the CV packet, a sliding window in the width of 3s is set on the source and the LSP status is checked by using the VC packet received in the sliding window. l To detect the source by using the FFD packet, a sliding window in the width of three times of FFD transmit interval is set on the source and the LSP status is checked by using the FFD packet received in the sliding window. 3. CV and FFD The FFD and CV detection packets are mutually exclusive. That is, only the FFD or CV detection packets can be applied to one LSP at a time. 4. Backward path BDI packets are transmitted through the backward path. The ingress of a backward path is the egress of the detected LSP, and the egress of the backward path is the ingress of the detected LSP. That is, each forward LSP has a backward path. 5. Protection switching (PS) When a fault occurs on the network, currently MPLS OAM provides the PS, a type of end to end tunnel protection technology, to recover the interrupted services. The PS uses one tunnel to protect another tunnel. There is no relation among the attributes of each tunnel in the protect group. For example, the protection tunnel with 10 Mbit/s bandwidth can protect a master tunnel with a requirement for 100 Mbit/s bandwidth.
MPLS OAM Detection Function

The basic process for MPLS OAM to detect the connectivity of a single LSP is as follows: l l The source transmits the CV/FFD packets to the destination through the detected LSP. The destination checks the correctness of the type and frequency information carried in the received detection packets and measures the number of correct and errored packets that are received within the detection period to monitor the connectivity of the LSP in real time. When the LSP fails, the destination detects the defect quickly and analyzes the defect type.
Bind a backward LSP to the detected LSP when configuring the OAM function for the detected LSP. A backward path is an LSP that has the opposite source and destination of the detected LSP, or a non-MPLS path that can be connected to the source and destination of the detected LSP. After the destination detects a defect, the destination transmits the BDI packets that carry the defect information to the source through the backward path. The source learns about the status of the defect, and triggers the corresponding protection switching when the protect group is correctly configured. Figure 7-7 shows the MPLS OAM CD.
Issue 01 (2011-10-30)
113
7 MPLS
Figure 7-7 MPLS OAM CD

Router MA5600T/ MA5603T
C
FD V/ F
CV /F F D
MA5600T/ MA5603T
Ingress LSR
BD I
Egress LSR
BDI
Router
Working Modes of the MPLS OAM Protection Switching

The MPLS OAM protection switching aims at the entire LSP instead of one section or one node on the LSP. The route and bandwidth of the standby LSP for a specified active LSP are reserved. Therefore, the protection switching is a thorough-assignment protection mechanism. To ensure that protection switching can be implemented effectively in all the possible cases that the active LSP fails, the standby LSP needs to use a physical path totally different from that of the active LSP. The working mode of MPLS OAM protection switching is 1:1 protection mode. In this mode, each active LSP has a standby LSP. l l In normal conditions, data is transmitted through the active LSP and no traffic is transmitted through the standby LSP. When the destination detects a failure on the active LSP through the detection mechanism, the destination switches to the standby LSP, and then transmits the BDI packet to the source through the backward path, instructing the ingress to switch the traffic on the active LSP to the standby LSP. Thus, 1:1 protection switching is implemented.

This topic provides the glossary, acronyms, and abbreviations of the MPLS feature.
Issue 01 (2011-10-30)
114
7 MPLS
Glossary
Table 7-3 Glossary of the terms related to the MPLS feature Term Description MPLS, as a classification and forwarding technology, assigns the packets with the same forwarding and processing mode to a class, called an FEC. The packets that belong to a particular FEC are processed in the same way on the MPLS network. The assignment of packets to FECs can be based on any combination of the source address, destination address, source port, destination port, protocol type, and VPN, which is flexible. For example, in the conventional IP forwarding using the maximum matching algorithm, all the packets to the same destination address belong to an FEC. A label is a short fixed length physically contiguous identifier which is used to identify an FEC, usually of local significance. In certain conditions, for example, when load sharing is required, one FEC may map multiple labels. On one device, however, one label can represent only one FEC. The packets with the same destination address are assigned to an FEC and a label is taken out of the label resource pool and is allocated to this FEC. The label switching node records the relationship between the label and the FEC, encapsulates the relationship into the message packet, and notifies the upstream label switching node of it. This process is called label distribution. The value range of the allocated labels is called the label space. LSRs are the basic elements in an MPLS network. All LSRs support the MPLS protocol. Label switching router (LSR) An LSR consists of a control unit and a forwarding unit. The control unit is responsible for label distribution, route selection, setup of the label forwarding table, and setup and release of the LSP. The forwarding unit forwards the received packet according to the label forwarding table. An LER provides the traffic classification, and label mapping (in this case, the LER is an ingress) and label removal functions. An LER (called the ingress LER), on the edge of the MPLS network, assigns the traffic that enters the MPLS network to different FECs, and applies for corresponding labels for these FECs. The path that an FEC traverses in an MPLS network is called the LSP. Label switched path (LSP) The LSP, whose function is the same as the virtual circuit in ATM and frame relay, is a unidirectional path from the ingress to the egress. Each node on the LSP is an LSR. LDP, equal to the signaling protocol in the traditional network, is the MPLS control protocol. LDP is responsible for series of operations such as FEC assignment, label distribution, and LSP setup and maintenance.
Forwarding equivalence class (FEC)
Label
Label distribution
Label space
Label switching edge router (LER)
Label distribution protocol
Issue 01 (2011-10-30)
115
7 MPLS
Term Static LSP Dynamic LSP
Description The static LSP is the label forwarding path manually set up by the user for label distribution to each FEC. The dynamic LSP is the label forwarding path dynamically established through the LDP. Traffic engineering is a technology which is used to adjust the traffic management parameters, route parameters, and resource constraint parameters in real time by dynamically monitoring network traffic and load of network elements. This helps to optimize the usage of network resources and avoid congestion due to unbalanced load. Multiple LSP tunnels are needed during reroute deployment, or when traffic needs to be transmitted through multiple paths. In TE, such a set of LSP tunnels is called the TE tunnel. Ps refer to the backbone devices on the service provider's network, which are not directly connected to CEs. Ps only need to possess the basic MPLS forwarding capability, but do not need to maintain the VPN information. PEs refer to the edge devices on the service provider's network. In the basic architecture of the MPLS-based VPN, PEs are located in the backbone network. PEs are responsible for the management of VPN users, establishment of LSPs among PEs, and route assignment among the tributaries within a VPN user. A PE maps and forwards packets from the private network to the public network tunnel or from the public network tunnel to the private network. PEs can be classified into U-PEs, S-PEs, and N-PEs. S-PEs refer to the devices responsible for PW switching and PW label forwarding in the internal of the backbone network. The core devices that are located in the interior of the basic VPLS full-connection network and are connected to UPEs are called the superior PEs, abbreviated as SPEs. The U-PE connected to the S-PE is like a CE and the PW established between the U-PE and the S-PE is treated as the AC of the S-PE. The S-PE needs to learn the MAC addresses of all the sites on the U-PE, and the MAC address of the U-PE interface connected to the SPE. The S-PE is sometimes called the N-PE. User-side PEs (U-PEs) refer to the edge devices on the backbone network that are connected to the user edge devices in a VPN network. A PE that is directly connected to a CE is called a U-PE. U-PEs support routing and MPLS encapsulation. If a U-PE is connected to multiple CEs and possesses the basic bridging function, data frame forwarding only needs to be performed on the U-PE. This reduces the load of the S-PE. Terminate PEs (T-PEs) refer to the devices that initiate or terminate PWs. The path from a PE to another PE, and then to another AC can be a pointto-point or point-to-multipoint connection between PEs.
Traffic engineering (TE)
MPLS TE tunnel
PE
S-PE
U-PE
T-PE PW
Issue 01 (2011-10-30)
116
7 MPLS
Term Single-hop PW Multi-hop PW Dynamic PW
Description A single-hop PW refers to the PW existing between two T-PEs. In the case of a single-hop PW, the label switching at the PW label layer is not needed. Multi-hop PWs refer to the multiple PWs existing between two T-PEs. Dynamic PW refers to the PW set up through the signaling protocol. PWE3 is a general name for all the services that traverse the PSN to the peer CE. The intermediate transmission media of the services can be the same or not, and end-to-end management of the services can be implemented. The essential attributes of the ATM/Ethernet service are emulated on a non-ATM/Ethernet network. Check whether a path is smooth and normal. Connectivity verification is implemented through CV and FFD. l CV is used to check whether the LSP is valid. l FFD is used to supports the functions that require quick response, such as protection switching. CV verification packets are generated on the source LSR at an interval of 1s, are transmitted along the LSP from the source LSR to the destination LSR, and are terminated on the source LSR of the LSP. A CV packet contains the trail termination source identification (TTSI), which uniquely identifies the network path. All types of abnormally on the path can be detected. FFD is a path failure detection method independent of CV. Different from CV, the interval for generating the detection packets can be set to meet different service requirements. By default, this interval is 20s. The FFD packet contains the information the same as that of the CV packet, and the processing on the FFD packets by the destination LSR is the same as the processing on the CV packets. FDI packets are used to respond to the detected failure events. The major function of the FDI packet is to suppress the alarms on the network layer that occur after failure. Its primary purpose is to suppress alarms being raised at affected higher level client LSPs and (in turn) their client layers. The purpose of the BDI OAM function is to inform the upstream end of an LSP of a downstream defect. The BDI packet can be used in the 1:1 or 1:n protection switching service. Protection switching refers to the function that MPLS OAM exchanges or duplicate traffic between the active tunnel and the standby tunnel. An LSP that is used to protect the active LSP. A bypass LSP is generally in the idle state and does not carry services. When the active LSP fails, the service data is forwarded by the bypass LSP continuously.
PWE3
ATM/Ethernet emulation
Connectivity Verification
CV packet
FFD packet
FDI packet
BDI packet Protection switching
Bypass LSP
Issue 01 (2011-10-30)
117
7 MPLS
Term Facility backup
Description A local repair method in which a bypass tunnel is used to protect one or more protected LSPs. A TE FRR mode of protecting the node that exists between the PLR and the MP, and is on the active LSP. When this node fails, traffic can be switched to the bypass LSP. A TE FRR mode of protecting the direct link between the PLR and the MP, and is along the active LSP. When this link fails, traffic can be switched to the bypass LSP. The point of local repair is the ingress of the bypass LSP. IETF extends the protocols (such as OSPF, IS-IS, BGP, LDP, and RSVP) that are related to IP/MPLS forwarding to implement uninterrupted forwarding during the protocol restart, and thus to suppress the change of the control-layer protocol to a certain extent during the active/standby switchover of the system. This series of standards are generally termed as the graceful restart extension for each protocol, abbreviated as the GR. A VC refers to a unidirectional logical connection between two nodes. VCCV is a tool for manually checking the connectivity of virtual circuits. Similar to ICMP ping and LSP ping, it is realized through the extended LSP ping.
Node protection
Link protection Point of local repair
GR
VC VCCV

Table 7-4 Acronyms and abbreviations of the MPLS feature Acronym/Abbreviation MP CBU MPLS BDI DoD DU FEC FDI FFD FR
Issue 01 (2011-10-30)
Full Spelling Merge Point Cellular Backhaul Unit Multi-Protocol Label Switch Backward Defect Indication Downstream-on-Demand Downstream Unsolicited Forwarding Equivalence Class Forward Defect Indication Fast Failure Detection Frame Relay
118
7 MPLS
Acronym/Abbreviation FRR LER LDP LSA LSP LSR TE TEDB SPF CSPF AC CE PE PLR PSN PW PWE3 MH-PW SH-PW OAM RSVP RSVP-TE GR HA ICMP IGP
Full Spelling Fast Reroute Label Switching Edge Router Label Distribution Protocol Link State Advertisement Label Switched Path Label Switching Router Traffic Engineering TE Database Shortest Path First Constraint Shortest Path First Attachment Circuit Customer Edge Provider Edge Point of Local Repair Packet Switched Network Pseudo wire Pseudo wire Emulation Edge-to-Edge Multi-Hop Pseudo-Wire Single-Hop Pseudo Wire Operations And Maintenance Resource Reservation Protocol RSVP-Traffic Engineering Graceful Restart High Availability Internet Control Message Protocol Interior Gateway Protocol
Issue 01 (2011-10-30)
119
8 Layer 2 VPN
8
About This Chapter
Layer 2 VPN
8.1 PWE3 PWE3 is an end-to-end Layer 2 service carrying technology and is a type of point-to-point L2VPN technology. PWE3 is proposed by the IETF PWE3 working group as one of the solutions for connecting the traditional communication network with the PSN network. 8.2 Native TDM In Native TDM, TDM frames are directly encapsulated to GPON GEM frames in TDMoGEM mode. This mode features simple encapsulation, small network cost, and guaranteed link quality. 8.3 Glossary, Acronyms, and Abbreviations This topic provides the glossary, acronyms, and abbreviations of the Layer 2 tunnel emulation feature.
Issue 01 (2011-10-30)
120
8 Layer 2 VPN
8.1 PWE3
PWE3 is an end-to-end Layer 2 service carrying technology and is a type of point-to-point L2VPN technology. PWE3 is proposed by the IETF PWE3 working group as one of the solutions for connecting the traditional communication network with the PSN network.
8.1.1 Introduction
Definition
Pseudo-wire emulation edge to edge (PWE3) is a type of Layer 2 service carrying technology. It is mainly used to emulate the essential behavior and characteristics of the services such as the ATM, frame relay, Ethernet, low-rate time division multiplexing (TDM) circuit, and synchronous optical network (SONET)/synchronous digital hierarchy (SDH) as faithfully as possible in a packet switched network (PSN). PWE3 is implemented on access devices through MPLS and IP technologies. MPLS supports PWE3 by using the LDP or RSVP-TE protocol as signaling.
Purpose
PWE3 can interconnect the traditional network with PSN to share resources and expand the reach of networks. For example, PWE3 can emulate services such as TDM, ATM, and Ethernet, and can implement service interoperation by using existing PSN (IP/MPLS) as the bearer network.
Benefit
PWE3 connects the traditional TDM, ATM, and Ethernet networks with PSN (IP/MPLS). In this way, PWE3 protects the investment on the traditional TDM, ATM, and Ethernet networks, and also implements the all-IP network architecture.
The MA5600T/MA5603T supports the following specifications of the pseudo wire emulation edge-to-edge (PWE3) feature: l l l l l l l l l
Issue 01 (2011-10-30)
Supports 896 static pseudo wires (PWs). Supports 2048 dynamic PWs. Supports single-hop PWs. Functions as a user-end provider edge (U-PE) but not as a switching provider edge (S-PE) in the multi-hop scenario. Supports the Label Distribution Protocol (LDP) for dynamic PW. Supports PW committed access rate (CAR). Functions as a provider edge (PE). Functions as a provider (P) device. Supports PW single hop virtual circuit connectivity verification (SH-VCCV).
8 Layer 2 VPN
Supports the following TDM PWE3 specifications: Structure-agnostic time division multiplexing over packet (SAToP) TDM connections Configuration of the TDM PW priority Encapsulation of the recovery clock information in the RTP header Two PWE3 tunnel encapsulation formats: multiprotocol label switching (MPLS) over MPLS and MPLS over IP
Supports the following ATM PWE3 specifications: Two PW encapsulation formats: ATM N-to-1 (N 1) and ATM service data unit (SDU) PVC switching and bulk binding of N-to-1 ATM PWs in ATM N-to-1 (N > 1). Cell concatenation Transparent transmission of the ATM OAM cells in the ATM PWE3 tunnel Mapping of the user PVC to the EXP field in the MPLS label Copying of the CoS priority in the ATM over Ethernet (AoE) header to the EXP field in the MPLS label upstream, and copying of the EXP field in the MPLS label to the CoS priority in the AoE header downstream PW-based CoS re-marking for two rate three color marker (trTCM) control (on the SPUB board) Two PWE3 tunnel encapsulation formats: MPLS over MPLS and MPLS over IP A maximum of 512 concatenated ATM PWE3 cells A maximum of 8192 AoE service flows
Supports the following ETH PWE3 specifications: Two PW encapsulation formats: tagged mode and raw mode Mapping of the VLAN priority to the EXP field in the MPLS label Only one encapsulation format: MPLS over MPLS
Supports flow label for ETH PW only but not for ATM PW or TDM PW. Flow label when functioning as a PE Flow label when functioning as a P device A maximum of 256 flow labels, which are shared by all PWs in the system. Different PWs can have the same flow label. Each PW can be further divided into a maximum of 256 traffic streams. Two load-balancing paths (only LSP paths, not RSVP-TE paths) for each PW Traffic classification modes for flow labels: by source IP address, by destination IP address, by source MAC address, by destination MAC address, or any combination of the preceding four modes
Supports the configuration and binding of the MPLS priority mapping profile for PWs.
NOTE
Currently, only the SCUN control board supports this function.
Configuration of the priority mapping between the EXP field and the CoS value in the user AoE packet in the MPLS priority mapping profile, priority copying for QoS scheduling during PW encapsulation and decapsulation A maximum of 64 configured MPLS priority mapping profiles in the system
8 Layer 2 VPN

The following lists the reference standards and protocols of this feature. l l l l l l l l l l l l l RFC 3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture RFC 4447: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) RFC 3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) RFC 4446: IANA Allocations for Pseudo wire Edge to Edge Emulation (PWE3) RFC 4717, Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks RFC 4816, Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks RFC 5085: PW vccv A control Channel for PW RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) RFC 5462: Multi-Protocol Label Switching (MPLS) Label Stack Entry EXP Field Renamed to Traffic Class Field RFC 4385: Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN draft-ietf-pwe3-redundancy-bit-00.txt draft-bryant-filsfils-fat-pw-03.txt
8.1.4 Availability
License Support
The PWE3 feature is a basic feature of the MA5600T/MA5603T. Therefore, the corresponding service is provided without a license.
Version Support
Table 8-1 Version support Product MA5600T/ MA5603T Version V800R007 and later versions (V800R009 dose not support PWE3)
Hardware Support
To implement TDM PWE3, the CSPA or TOPA board needs to work with the SPUB board, or the EDTB board needs to work with the SPUB board.
8.1.5 Enhanced Feature

Table 8-2 lists the new pseudo wire emulation edge-to-edge (PWE3) functions added to the new versions.
8 Layer 2 VPN
Table 8-2 Enhanced PWE3 feature Version V800R008C01 New Function l Functions as a P device. l Supports PW flow label. V800R008C02 l Supports PVC switching and ATM PW N-to-1 (N > 1) encapsulation. l Supports ATM PWE3 cell concatenation. l Supports PW-based dual-bucket CAR. V800R010 l Supports PW Redundancy. l Supports the configuration and binding of the MPLS priority mapping profile for PWs.
8.1.6 Principle
8.1.6.1 Basic Principle of PWE3 Basic PWE3 Transmission Components
Pseudo wire emulation edge-to-edge (PWE3), which uses LDP and RSVP-TE as the signaling protocols, carries various types of Layer 2 services, such as various types of Layer 2 data packets, from the customer edge (CE), and transparently transmits the Layer 2 data through tunnels (such as MPLS LSP, TE, or GRE tunnels). As shown in Figure 8-1, the basic PWE3 transmission components include the following: l Attachment circuit (AC): a link between CE and PE. All user packets (including Layer 2 and Layer 3 protocol packets of users) on the AC are transparently forwarded to the peer end. Pseudo wire (PW): a virtual connection. It is a virtual connection (VC) plus a tunnel. A PW conveys VC information by signaling (LDP or RSVP-TE). The tunnel can be an LSP, L2TPV3, GRE, or TE tunnel. A PW is directional. A PWE3 conveys VC information by signaling (LDP or RSVP-TE). The system manages VC information and tunnels to form PWs. For the PWE3 system, a PW is like a direct channel between a local AC and a peer AC and is used for transparently transmitting the Layer 2 data of users. Forwarder: After a PE receives data frames from an AC, the forwarder selects a PW for forwarding the frames. In fact, the forwarder is a forwarding table of PWE3. Tunnel: A tunnel is a direct channel between a local PE and a peer PE and is used for transparently transmitting data between the PEs. Tunnels are used for carrying PWs. A tunnel can carry multiple PWs. Generally, the tunnel refers to an MPLS tunnel. PW signaling protocol: A PW signaling protocol is the basis for implementing PWE3 and is used to create and maintain PWs. Current PW signaling protocols are mainly LDP and RSVP-TE. Encapsulation: The packets transmitted through the PW use the standard PW encapsulation format and technology. There are multiple PWE3 encapsulation types on a PW. The formats are defined in detail in draft-ietf-pwe3-iana-allocation-x.
l l
Issue 01 (2011-10-30)
8 Layer 2 VPN
Quality of service (QoS): The priority information at the header of Layer 2 user packets is mapped to the QoS priority for transmitting the packets in the public network. In general, support for MPLS QoS is required.
Figure 8-1 Basic PWE3 transmission components
Assume that the VPN1 packet stream travels from CE1 to CE3. The basic data flow would be as follows: l l l CE1 transmits a Layer 2 packet to PE1 through an AC. After PE1 receives the packet, the forwarder selects a PW for forwarding the packet. PE1 generates two MPLS labels according to the PW forwarding entry. The private network label is used for identifying the PW, and the public network label is used for transmitting the packet to PE2 through the tunnel. The Layer 2 packet arrives at PE2 through the public network tunnel. The system extracts the private network label (the public network label is extracted by the penultimate P device). The forwarder of PE2 selects an AC for forwarding the packet, and then PE2 forwards the packet to CE3.
l l
PWE3 Network Model

Figure 8-2 shows a PWE3 reference model.
Issue 01 (2011-10-30)
125
8 Layer 2 VPN
Figure 8-2 PWE3 network model

Emulated service Pseudo wire PW end service PSN tunnel PW end service
CE1
PE1
Tunnel
PE2
CE2
Custom edge 1 Native Ethernet service
Provider edge 1
Provider edge 2
Custom edge 2 Native Ethernet service
The channel set up in a PWE3 network is a point-to-point channel. Channels are isolated from each other. Layer 2 user packets are transparently transmitted between PWs. The following provides a detailed description. l l l According to the services requirements of the CE, one or more PWs are set up between PE1 and PE2. Multiple PWs can be carried on one PSN tunnel. For the PEs, after the PW is set up, the mapping between the user access interface (AC) and virtual link (PW) is determined. The PSN device only needs to forward the MPLS packet according to the MPLS label, regardless of the Layer 2 user packet encapsulated inside the MPLS packet.
PWE3 Service Model

Figure 8-3 shows a PWE3 service model. According to the PWE3 service model, PWE3 is presented by an outer label (PSN tunnel) and an inner label (PW demultiplexer). The PSN layer can adopt the MPLS and IP technologies, and the PW demultiplexer layer can adopt the MPLS, UDP, or L2TP technology. Hence, the supported combinations of PWE3 outer labels and inner labels are as follows: MPLS over MPLS, MPLS over IP, UDP over IP, and L2TP over IP. The MA5600T/MA5603T currently supports the first three combinations.
Issue 01 (2011-10-30)
126
8 Layer 2 VPN
Figure 8-3 PWE3 service model
Payload
May be null
Encapsulation PW demultiplexer PSN convergence PSN Data link Physical
May be null
Figure 8-4 shows the PWE3 protocol stack in the MPLS over MPLS encapsulation mode. Figure 8-4 PWE3 protocol stack in the MPLS over MPLS encapsulation mode
LSP PE Modem P PW P PE Modem
IP ETH xDSL
IP ETH PW1 LSP1 VLAN ETH
IP ETH xDSL
PW: PW label (inner label), identifying user service LSP: MPLS label (outer label), identifying PSN tunnel
Figure 8-5 shows the PWE3 protocol stack in the MPLS over IP encapsulation mode.
Issue 01 (2011-10-30)
127
8 Layer 2 VPN
Figure 8-5 PWE3 protocol stack in the MPLS over IP encapsulation mode
IP tunnel PE Modem P PW P PE Modem
IP ETH xDSL
IP ETH PW1 IP1 VLAN ETH
IP ETH xDSL
PW: PW label (inner label), identifying user service IP: IP tunnel (outer label), identifying PSN tunnel
Figure 8-6 shows the PWE3 protocol stack in the UDP over IP encapsulation mode. Figure 8-6 PWE3 protocol stack in the UDP over IP encapsulation mode
IP tunnel PE Modem P PW (UDP) P PE Modem
IP ETH xDSL
IP ETH UDP1 IP1 VLAN ETH
IP ETH xDSL
UDP: UDP port number (inner label), identifying user service IP: IP tunnel (outer label), identifying PSN tunnel
Figure 8-7 illustrates the principle of PW label distribution.

8 Layer 2 VPN
Figure 8-7 Principle of PW label distribution
XDSL
XDSL
PE
PE
Routing LSP label PW label
Static/dynamic routes Static/dynamic routes Static/dynamic routes LDP/RSVP LDP/RSVP Targeted LDP LDP/RSVP
Packet Format
PWE3 has three packet formats: MPLS+PW, IP+PW, and IP+UDP. The MA5600T/ MA5603T currently supports MPLS+PW and IP+PW. l MPLS+PW: In this packet format, the combination of PWE3 outer label and inner label is MPLS over MPLS. It is applicable to MPLS network transmission. Figure 8-8 shows the format of an MPLS+PW PWE3 packet. Figure 8-8 Format of an MPLS+PW PWE3 packet
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Label | EXP |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|L|R|RSV|FRG| LEN | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt|RTV|P|X| CC |M| PT | RTP Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| SSRC identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Adapted Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP+PW: In this packet format, the combination of PWE3 outer label and inner label is MPLS over IP. It is applicable to MPLS over IP network transmission. Different from MPLS+PW packets, IP+PW packets are forwarded at IP Layer 3 when transmitted over the PSN network. Figure 8-9 shows the format of an IP+PW PWE3 packet.
Issue 01 (2011-10-30)
129
8 Layer 2 VPN
Figure 8-9 Format of an IP+PW PWE3 packet

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPVER | IHL | IP TOS +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protoc +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sourc +-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destinat +-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW label +-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|L|R|RSV|FRG| LEN +-+-+-+-+-+-+-+-+-+-+-+-+-+ opt|RTV|P|X| CC |M| PT +-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| +-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| S +-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Ad | +-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 4 5 6 -+-+-+-+ | -+-+-+-+ |Fl -+-+-+-+ ol | -+-+-+-+ e IP Add -+-+-+-+ ion IP A -+-+-+-+ -+-+-+| -+-+-+| -+-+-+Times -+-+-+SRC ide -+-+-+apted P 3 9 0 1 -+-+-+ | -+-+-+ t | -+-+-+ | -+-+-+ | -+-+-+ | -+-+-+ | + -+-+-+ | + -+-+-+ | + -+-+-+ t | + -+-+-+ n | + -+-+-+ | ayload | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 7 8 9 0 1 2 3 4 5 6 7 8 -+-+-+-+-+-+-+-+-+-+-+-+ Total Length -+-+-+-+-+-+-+-+-+-+-+-+ ags| Fragment Offse -+-+-+-+-+-+-+-+-+-+-+-+ IP Header Checksum -+-+-+-+-+-+-+-+-+-+-+-+ ress -+-+-+-+-+-+-+-+-+-+-+-+ ddress -+-+-+-+-+-+-+-+-+-+-+-+ | EXP |1| TTL -+-+-+-+-+-+-+-+-+-+-+-+ Sequence number -+-+-+-+-+-+-+-+-+-+-+-+ RTP Sequence Number -+-+-+-+-+-+-+-+-+-+-+-+ amp -+-+-+-+-+-+-+-+-+-+-+-+ tifier -+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-
IP+UDP: In this packet format, the combination of PWE3 outer label and inner label is UDP over IP. It is applicable to IP network transmission. Different from MPLS+PW packets, IP+UDP packets are forwarded at IP Layer 3 and meanwhile forwarded at Layer 2 by UDP port redirection when transmitted over the PSN network. Figure 8-10 shows the format of an IP+UDP PWE3 packet. Figure 8-10 Format of an IP+UDP PWE3 packet
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| IPVER | IHL | IP TOS | Total Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identification |Flags| Fragment Offset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Time to Live | Protocol | IP Header Checksum +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source IP Address | Destination IP Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Port Number | Destination Port Number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| UDP Length | UDP Checksum +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+opt|RTV|P|X| CC |M| PT | RTP Sequence Number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+opt| Timestamp +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+opt| SSRC identifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RES |L|R| M |RES| Length | Sequence Number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | Adapted Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
8.1.6.2 Principle of TDM PWE3 Packet Format

When the TDM service is transmitted over the PSN, there are two packet encapsulation formats, namely, structure-aware packet format and structure-agnostic packet format. The structureaware packet, which is also called CESoPSN packet, is defined in RFC5086 and RFC5687. The structure-agnostic packet, which is also called SAToP packet, is defined in RFC4553.
8 Layer 2 VPN
Circuit emulation service over packet switched network (CESoPSN) is a generic term for circuit emulation service and also refers to structure-aware circuit emulation. 1. CESoPSN packet format (structure-aware packet format) The CESoPSN standard provides the channelized TDM service with emulation and transmission functions, and can identify the TDM frame structure and in-frame signaling. Therefore, if the customer needs to provide services based on the timeslot, the CESoPSN packet format can meet this requirement. Figure 8-11 shows the format of the CESoPSN packet. Figure 8-11 CESoPSN packet format
0 MPLS Label PW Label 0 0 0 0 L R RSV FRG LEN RTP header Time slot 1 Time slot 5 Time slot 1 Time slot 5 Time slot 2 Time slot 3 Time slot 4 20 EXP EXP 23 S 1 TTL TTL 31
Sequence Number
Time slot n (Frame 1#) Time slot 2 Time slot 3 Time slot 4
Time slot n (Frame 2#) Time slot n (Frame m#)
l A CESoPSN packet contains a four-byte MPLS header and a four-byte PW header. The length of the CESoPSN control word is 4 bytes, including fields as shown in Table 8-3. l The length of the Real-Time Transport Protocol (RTP) header is 12 bytes, including the version number, padding flag, and time stamp fields. The time stamp field, whose length is 32 bits, is used for clock synchronization. For format of the RTP header, see RFC3550. l Time slot indicates the TS in the TDM frame. Each TS occupies 8 bits. All TSs comprise the encapsulated TDM data payload, which does not include the CRC bit. The number of encapsulated frames and the number of TSs in each frame can be set by users according to conditions. Table 8-3 Fields of the control word Field 0000 Description This field is generally all 0s, with the length of 4 bits. When the virtual circuit connectivity verification (VCCV) is needed to help to monitor the SAToP PW status, these four bits are used to identify the start of the associated channel header (ACH).
8 Layer 2 VPN
Field L
Description Indicates whether the TDM data in the packet is valid. Its length is 1 bit. When it is set to 1, it indicates that the TDM data in the packet is invalid; that is, the TDM data in the packet can be neglected to save bandwidth resources. Indicates whether the interconnection function of the local customer edge (CE) is in the packet loss state. When it is set to 0, it indicates that consecutive packets have been received and will no longer be lost. Indicates the reserved bit. Its length is 2 bits. Indicates the fragmentation status of the packet. Its length is 2 bits. Its values are as follows: l 00: Indicates that the packet encapsulates the entire TDM data. l 01: Indicates that the packet encapsulates the first fragmentation of the TDM data. l 10: Indicates that the packet encapsulates the last fragmentation of the TDM data. l 11: Indicates that the packet encapsulates the intermediate fragmentation of the TDM data.
RSV FRG
LEN
Indicates the length of the entire CESoPSN packet (the size of the CESoPSN header and TDM data.) When the length is shorter than 64 bytes, LEN is a specific length value. When the length is equal to or longer than 64 bytes, LEN is 0. Indicates the sequence number for transmitting the CESoPSN packet. Its length is 16 bits. Its initial value should be random. It must be incremented by 1 with each CESoPSN data packet sent in the specific PW.
Sequence Number
The CESoPSN packet structure has the following characteristics: l CESoPSN provides emulation and transmission of structure-aware TDM service. That is, CESoPSN can identify the TDM frame structure and in-frame signaling and transmit the frames. For example, a structure-aware E1 link consists of 32 timeslots. Except timeslot 0, the other 31 timeslots can each carry a channel of 64 kbit/s voice service. Timeslot 0 is used only for transmitting signaling and frame delimiter. l CESoP can identify the TDM frame structure. Therefore, idle timeslots are not transmitted, and only the data in the timeslots that are useful for the CE devices is retrieved from the E1 service stream and transmitted after being encapsulated into CESoPSN frames. l CESoPSN can identify and transmit the CAS and CCS signaling of E1 service streams. 2. SAToP packet format (structure-agnostic packet format) The structure-agnostic TDM over PSN (SAToP) standard provides the non-channelized TDM service with the emulation and transmission functions. The protocol need not be
8 Layer 2 VPN
aware of the structure of the TDM packets and transparently transmits the packets. Therefore, if the customer only needs to provide services based on E1, SAToP (unstructured packet format) can meet this requirement. Figure 8-12 shows the format of the SAToP packet. Figure 8-12 SAToP packet format
0 MPLS Label PW Label 0 0 0 0 L R RSV FRG LEN RTP header TDM data 20 EXP EXP 23 S 1 TTL TTL 31
Sequence Number
l An SAToP packet also contains a four-byte MPLS header and a four-byte PW header. The length of the SAToP control word is 4 bytes, including fields as shown in Table 8-3. l The SAToP protocol treats the TDM service as serial data code stream for segmentation, and transmits the service over PWs after encapsulation. SAToP can transmit the synchronization timing information although it is unaware of the structure of the TDM frame.
Service Processing Flow

The MA5600T/MA5603T supports E1 access, and also supports SAToP encapsulation and processing of E1 service. Figure 8-13 shows the service processing flow. Figure 8-13 Processing flow of TDM PWE3 service in E1 access
E1 EDTB board SAToP processing SAToP processing TDM TDM (RTP) CW MPLS/IP processing TDM (RTP) CW PW MPLS/IP upstream SPUB board MPLS/IP ETH processing encapsulation ETH encapsulation TDM (RTP) CW PW MPLS/IP VLAN ETH
IP/MPLS
Issue 01 (2011-10-30)
133
8 Layer 2 VPN
Packing/Unpacking of SAToP packets The MA5600T/MA5603T packs E1 data in the SAToP format, and adds the control word and RTP header (optional in the MPLS mode) to the SAToP packets.
Encapsulation of MPLS labels The MA5600T/MA5603T adds/deletes the MPLS labels, and maps inner labels to user circuits. In the MPLS+MPLS encapsulation, the outer LSP label is used for transmitting the packet over an MPLS network; in the IP+MPLS encapsulation, the outer IP address is used for transmitting the packet over an IP network. The inner label is used for mapping to a user circuit. The inner PW tunnel is a bidirectional MPLS tunnel that carries TDM data. A PW label can be statically configured or dynamically created through protocol (LDP). The outer tunnel can be MPLS-encapsulated or IP-encapsulated. In the case of MPLS encapsulation, the outer MPLS tunnel can be statically configured or dynamically created through protocol (LDP or RSVP-TE). In the case of IP encapsulation, the outer IP tunnel can be statically configured.
Ethernet processing: In the upstream direction, the ETH header is encapsulated to the packet label header, and then the packet is transmitted through the upstream port on the control board. The upstream VLAN of the TDM PWE3 packet is a service VLAN, which is the VLAN of the corresponding upstream port. The Layer 3 interface MAC address is filled in as the source MAC address of the TDM PWE3 upstream packet, and the MAC address of the next-hop interface (this MAC address can be learned through ARP) is used as the destination MAC address.
In the GPON access scenario, the MA5600T/MA5603T supports the native TDM solution (a Huawei proprietary protocol). Figure 8-14 shows the service processing flow. Figure 8-14 Processing flow of TDM PWE3 service in the native TDM solution
E1 ONU GPON board CSPA board Native adaptation TDM VC12 VLAN ETH CESoP processing TDM (RTP) CW VLAN ETH SPUB board MPLS/IP processing TDM (RTP) CW PW MPLS/IP ETH encapsulation TDM (RTP) CW PW MPLS/IP VLAN ETH IP /MPLS
TDM
TDM VC12 (ETH) GEM GPON
TDM
In the upstream direction, the ONT encapsulates the E1 service in the native TDM format (defined by Huawei), then encapsulates the native TDM packet as a payload into the GEM frame, and transmits the GEM frame to the OLT.
Issue 01 (2011-10-30)
134
8 Layer 2 VPN
The OLT terminates the GEM encapsulation of GPON and obtains the native TDM packet. Then, the OLT restores the E1 service from the native TDM packets, and encapsulates and processes the E1 service in a flow similar to that in E1 access.
QoS Processing
Figure 8-15 shows the QoS processing flow of TDM PWE3 service, considering the example of SAToP (MPLS over MPLS encapsulation). Figure 8-15 QoS processing flow of upstream SAToP service (MPLS over MPLS encapsulation)
User side PW E1 EXP1 EXP2 EXP3 LSP EXP1 EXP2 EXP3 VLAN CoS1 CoS2 CoS3 Queues S GE Network side
TDM
TDM PW EXP
TDM PW EXP LSP EXP
TDM PW EXP LSP EXP ETH
TDM connection mapped to PW, configured on manmachine interface
PW EXP copied to LSP EXP
LSP EXP mapped to ETH CoS
Packets sent to queues for PQ, WRR, and PQ+WRR scheduling
8.1.6.3 ATM PWE3 Principle Processing of ATM PWE3 PDUs

Figure 8-16 shows how ATM pseudo wire emulation edge-to-edge (PWE3) protocol data units (PDUs) are processed on the provider edge (PE) and provider (P) devices. The MA5600T/ MA5603T can function as a PE or a P device. The PE establishes an MPLS-based PW tunnel and encapsulates the user data packets (ATM cells or Ethernet packets) with two labels at the transmit (Tx) end for transmission. The P device forwards the packets. The PE at the receive (Rx) end decapsulates the received MPLS packets, restores the original user data packets, and transmits the packets to users.
Issue 01 (2011-10-30)
135
8 Layer 2 VPN
Figure 8-16 Processing of ATM PWE3 PDUs

Modem ADSL2+ PE P P PE ADSL2+ STM-1 Modem
STM-1
ATM DSLAM
ATM ADSL
ATM PW LSP VLAN ETH
ATM PW LSP VLAN ETH
ATM PW LSP VLAN ETH
ATM ADSL
ATM DSLAM
N-to-1 protocol stack
Processing of ATM PWE3 Service

Figure 8-17 shows how the ATM PWE3 service (MPLS over IP or MPLS over MPLS encapsulation) is processed. Figure 8-17 Processing of ATM PWE3 service
MA5600T/MA5603T IP/MPLS encapsulation ATM ATM CW ATM CW PW IP/MPLS ETH encapsulation ATM CW PW IP/MPLS VLAN Upstream direction ETH IP/MPLS
Encapsulation/Decapsulation of ATM cells A control word is added to an ATM cell. Figure 8-18 shows the format of the control word. Figure 8-18 Format of the control word for an ATM cell
l
Issue 01 (2011-10-30)
MPLS over IP encapsulation (MPLS over MPLS encapsulation is the same.)

8 Layer 2 VPN
The IP header and the PW label are added/deleted, and the PW label is mapped to a permanent virtual connection (PVC). The outer IP header is used for transmitting the packet through the IP network, and the PW label is used for mapping to a PVC. The source IP address in the IP header is the IP address of the Layer 3 interface, and the destination IP address is the IP address of the peer end (identical to the peer-address configured in the PW template). The ToS bit needs to be configured by users. The value of the protocol field is 137 (identifying an MPLS unicast packet), the value of the DF bit is 1, and that of the MF bit is 0. l Ethernet processing The upstream VLAN of the ATM PWE3 PDU is a service VLAN, which is the VLAN of the corresponding upstream port. The MAC address of the Layer 3 interface is filled in as the source MAC address of the ATM PWE3 upstream PDU, and the MAC address of the next-hop interface (this MAC address can be learned only by ARP) is used as the destination MAC address.
ATM PW N-to-1 (N > 1) Encapsulation

The following encapsulation formats are defined in the RFC4717 for the PWE3 emulation of ATM services in a packet-switched network (PSN). The MA5600T/MA5603T supports N-to-1 (N 1) and ATM adaptation layer 5 (AAL5) service data unit (SDU) encapsulation. l l l l N-to-1 (N > 1): Multiple ATM virtual channel connections (VCCs) or virtual path connections (VPCs) are transported in one PW. 1-to-1: Only one ATM VCC or VPC is transported in one PW. AAL5 SDU: Only the AAL5 CPCS-SDU payload is transported. AAL5 PDU: The AAL5 PDU, together with the PAD and CPCS-PDU, is transported.
For the N-to-1 (N > 1) ATM PWE3, user cells in multiple user-side PVCs are encapsulated into one PW. In order for the Rx end to differentiate these cells, the ATM service payload in a PW needs to contain the VPI/VCI information about the cells and the VPI/VCI information about each cell needs to be unique. During user service provisioning by carriers, however, the VPI/ VCI values of all user PVCs are the same. As such, VPI/VCI switching is required when user PVCs are encapsulated into a PW to ensure unique VPI/VCI values for cell differentiation. The MA5600T/MA5603T supports the following two PVC (VPI/VCI) switching methods. l The peer PE transparently transmits PVCs and does not perform downstream PVC switching, as shown in Figure 8-19. In the upstream direction, PVC switching is performed on ingress PE1 for the cells with the same VPI/VCI values from different ports. This is to ensure the uniqueness of VPI/ VCI values in a PW. After the cells are transmitted upstream to egress PE2, egress PE2 transparently transmits the cells without downstream PVC switching. In the downstream direction, ingress PE2 does not perform PVC switching in the inbound direction but transparently transmits the cells to egress PE1. Egress PE1 then performs PVC switching and transmits the cells to the AC-side xDSL port.
Issue 01 (2011-10-30)
137
8 Layer 2 VPN
Figure 8-19 PVC switching method 1: transparently transmitting PVC by the peer PE
User-side PVC cells Access node Cells in a PW ATM PW GW
Port 1, 0/35 Switches PVCs upstream and downstream Port 2, 0/35
Outbound Inbound Outbound Inbound PE1
2/32 2/32 2/33 2/33
Inbound Outbound Inbound Outbound PE2
2/32 Transparently transmits PVCs 2/33
The peer PE performs downstream PVC switching, as shown in Figure 8-20. In the upstream direction, PVC switching is performed on ingress PE1 with the same VPI/VCI values from different ports. This is to ensure the uniqueness of VPI/VCI values in a PW. After the cells are transmitted upstream to egress PE2, egress PE2 performs downstream PVC switching. In the downstream direction, ingress PE2 does not perform PVC switching in the inbound direction but transparently transmits the cells to egress PE1. Egress PE1 then performs PVC switching and transmits the cells to the AC-side xDSL port. Figure 8-20 PVC switching method 2: downstream PVC switching by the peer PE
User-side PVC cells Access Node Cells in a PW 1/32 2/32 1/33 2/33 ATM PW GW
Port 1, 0/35 Switches PVCs upstream and downstream Port 2, 0/35
Outbound Inbound Outbound Inbound PE1
Inbound Outbound Inbound Outbound PE2
2/32 Switches PVCs only downstream 2/33
ATM Cell Concatenation

In order to improve transport efficiency on the PSN, multiple ATM cells are encapsulated in a single PW PDU. This process is called ATM cell concatenation. With cell concatenation, cell transfer delay and jitter in the link are increased although the encapsulation efficiency is improved. For example, the more the cells are concatenated, the greater the delay of sending encapsulated cells. The MA5600T/MA5603T provides two parameters, maximum number of concatenated cells and maximum encapsulation delay of cells, for balance. As shown in Figure 8-21, during encapsulation of the concatenated cells, the cells are sent once the maximum encapsulation delay of cells or the maximum number of concatenated cells is reached.
8 Layer 2 VPN
Figure 8-21 Maximum number of concatenated cells and maximum encapsulation delay of cells
PW playload 2 1 1
3 2 1 4 5 4
Maximum number of concatenated cells
Cells
5 t
Maximum encapsulation delay of cells
QoS Processing of ATM PWE3 Service

Figure 8-22 shows the QoS processing of the ATM PWE3 service (MPLS over MPLS encapsulation). Figure 8-22 QoS processing of upstream ATM PWE3 service (MPLS over MPLS encapsulation)
User side PW ATM EXP1 EXP2 EXP3 IP ToS1 ToS2 ToS3 VLAN CoS1 CoS2 CoS3 Queues S GE Network side
ATM
ATM PW EXP
ATM PW EXP LSP EXP
ATM PW EXP LSP EXP ETH
PVC mapped to PW, configured on man-machine interface
PW EXP copied to IP ToS
Packets sent to queues for PQ, WRR, and PQ+WRR scheduling
Issue 01 (2011-10-30)
139
8 Layer 2 VPN
PW-based Dual-Bucket CAR

QoS is required for the user ATM cells carried in ATM PWE3 over the PSN network. Due to mechanism differences, the ATM traffic policing mechanism needs to map the MPLS traffic policing mechanism on an ingress PE, and a reverse mapping is required on an egress PE. In the upstream direction of an ingress PE, PW-based dual-bucket CAR, that is, two rate three color marker (trTCM), is performed according to PW CAR or LSP CAR. With this mechanism, ATM cells whose rate is lower than committed information rate (CIR) are marked with the default CoS value of ATM over Ethernet (AoE) traffic streams, and ATM cells whose rate is higher than CIR and lower than peak information rate (PIR) are re-marked with a low-priority CoS value, while ATM cells whose rate is higher than PIR are dropped. During encapsulation of PW PDUs, the CoS of the AoE packet is mapped to the EXP field of the inner PW label and then to the EXP field of the outer MPLS label. Then, traffic policing is performed over the PSN network based on the EXP field of the outer MPLS label, as shown in Figure 8-23. In the downstream direction of an egress PE, the egress PE works with the ingress PE to put the ATM cells carrying the default CoS tag and those carrying the low-priority CoS tag into the same queue according to the CoS information carried in the EXP field. Also, different early drop thresholds are configured for these two CoS tags to ensure that ATM cells whose rate is lower than CIR have a higher priority when congestion occurs. In the upstream direction, the MA5600T/MA5603T implements PW-based dual-bucket CAR on the SPUB board, which achieves trTCM by CoS re-marking based on CIR and PIR, as shown in Figure 8-23. In the downstream direction, the MA5600T/MA5603T does not perform CAR or CoS-based tail drop on the SPUB board, but implements queue-based early drop on the xDSL board according to the CoS early drop threshold, as shown in Figure 8-24. Figure 8-23 PW-based dual-bucket CAR on the SPUB board (in the upstream direction)
IP DSLAM ATM IP PWE3 Gateway ATM
IP DSLAM
AOE cos 1 cos 4 cos 5 PWE3 cos 1-> exp 1 cos 4-> exp 4 cos 5-> exp 5
Router
PWE3 Gateway
ATM port1 exp1,0->queue0 exp4,2->queue1 exp5->queue3 ATM port2 exp1,0->queue0 exp4,2->queue1 exp5->queue3
UBR+
PIR CIR PIR CIR CIR
rt-VBR CBR
exp 1->exp 0 exp 1->exp 1 exp 4->exp 2 exp 4->exp 4

exp 5->exp 5
exp 0 exp 1 exp 2 exp 4 exp 5
xDSL
SPUB Dual bucket CAR based on PW PQ/WRR based on exp
Weighted Early Discard Threshole
Issue 01 (2011-10-30)
140
8 Layer 2 VPN
Figure 8-24 Threshold-based early drop on the xDSL board (in the downstream direction)
IP DSLAM ATM IP PWE3 Gateway ATM
IP DSLAM
xDSL port1 cos1,0->queue0 cos4,2->queue1 cos5->queue3 xDSL port2 cos1,0->queue0 cos4,2->queue1 cos5->queue3 cos 0 cos 1 cos 2 cos 4 cos 5 exp 0 exp 1 exp 2 exp 4 exp 5
Router
PWE3 Gateway
UBR+>MCR -> exp 0 UBR+ < MCR -> exp 1 VBR-rt > MCR -> exp 2 VBR-rt < MCR -> exp 4 exp 5
PCR
MCR
UBR+
PCR
MCR
VBR-rt
MCR
CBR
xDSL Weighted Early Discard Threshole
SPUB PQ/WRR based on exp Dual bucket CAR
When cell concatenation is used for binding of ATM cells to PWs, PVCs of the same type are generally bound to the same PW. Because the AoE CoS value of the ATM cells is copied as the CoS value of the PW, the AoE CoS priority is affected when cells of different priorities are concatenated. l When PW does not use cell concatenation, a PW PDU contains only one ATM cell. In this case, the AoE CoS value of the ATM cell is directly copied as the EXP value of the PW PDU. When PW uses cell concatenation, a PW PDU contains multiple ATM cells. In this case, if the AoE CoS values of these ATM cells are different, the CoS value indicating the highest priority will be copied as the EXP value of the PW PDU. Then, the AoE CoS values (equaling the EXP value of the PW PDU) of ATM cells in the same PW PDU will be the same in the downstream direction, which affects queue scheduling on the xDSL board.
8.1.6.4 Principle of ETH PWE3 Processing Flow of ETH PWE3 Protocol Packets
Two encapsulation formats are defined in RFC4448 for the PWE3 emulation of Ethernet service in a PSN network. l l Tagged mode. In this mode, the packet going upstream carries the PW VLAN tag in the payload, and is stripped of the PW VLAN tag when going downstream. Raw mode. In this mode, the packet going upstream does not carry the PW VLAN tag; the PW payload, however, can carry the service VLAN tag.
Figure 8-25 shows the processing flow of ETH PWE3 protocol packets on the PE and P devices. The MA5600T/MA5603T can function as a PE or a P device. The PE establishes an MPLSbased PW tunnel, encapsulates the user data packets with two labels at the Tx end and transmits the packets. The P device forwards the packets. The PE at the Rx end decapsulates the received MPLS packets, restores the original user data packets, and transmits the packets to the user.
8 Layer 2 VPN
Figure 8-25 Processing flow of ETH PWE3 protocol packets

PE Modem P P PE Modem
IP VLAN ETH xDSL
IP VLAN ETH PW LSP VLAN ETH
IP VLAN ETH xDSL
Tagged mode protocol stack
Processing Flow of ETH PWE3 Service

Figure 8-26 shows the processing flow of ETH PWE3 service (MPLS over MPLS encapsulation). Figure 8-26 Processing flow of ETH PWE3 service
OLT MPLS encapsulation ETH GE/FE ETH ETH PW MPLS ETH encapsulation ETH PW MPLS VLAN Upstream direction ETH MPLS
QoS Processing Flow of ETH PWE3 Service

Figure 8-27 shows the QoS processing flow of ETH PWE3 service (MPLS over MPLS encapsulation).
Issue 01 (2011-10-30)
142
8 Layer 2 VPN
Figure 8-27 QoS processing flow of upstream ETH PWE3 service (MPLS over MPLS encapsulation)
User side PW GE EXP1 EXP2 EXP3 LSP EXP1 EXP2 EXP3 VLAN CoS1 CoS2 CoS3 Queues S GE Network side
ETH
ETH PW EXP
ETH PW EXP LSP EXP
ETH PW EXP LSP EXP ETH
ETH CoS mapped to PW
PW EXP copied to LSP EXP
Packets sent to 8 queues for PQ, WRR, and PQ+WRR scheduling
8.1.6.5 Traffic Label Principle Context

As services are developing, service traffic over a PW becomes heavier and heavier. For example, in the case of the wholesale service, certain carriers encapsulate all service traffic on hundreds or thousands of xDSL ports into a PW, and as a result traffic over the PW reaches the gigabit level. As such, a PW carrying such a heavy traffic is called fat PW. The fat PW burdens the equipment that it traverses, and results in congestion, packet loss, and unguaranteed QoS. To solve problems incurred by the fat PW, IETF proposed a traffic label solution: Traffic over a fat PW takes different paths from the PW ingress PE to the PW egress PE within the network through load balancing (ECMP). To achieve PWE3 load balancing, PW data at the PW ingress PE are segmented into bundles of data streams and an MPLS label (traffic label) is allocated to every data stream. In this way, every traffic label identifies a different data stream and the traffic label is stored in the innermost area of the ingress PE label stack. Later, data is forwarded in the load balancing mode according to the traffic label, taking different data streams along different paths within the network. In terms of PW load balancing, data over a PW arrives at the destination along different paths and this may incur disordered packets. Given this, this technology is applicable to only those services that are not sensitive to disordered packets, such as the Ethernet service. For the ATM and TDM emulation services, this technology is not applied because they have strict requirements on timing and order of packets. PW load balancing is implemented based on equal cost LSP that is based on the equal cost route.
Issue 01 (2011-10-30)
143
8 Layer 2 VPN
Application Description
Figure 8-28 shows an application over an existing network where a large amount of the legacy equipment does not support the traffic label. In this application, the PE supports generating the traffic label and performing load balancing but the P has no traffic label capability (for example, the legacy equipment over the network). l l PE1 generates traffic label (FL) and at the same time performs load balancing (flow1 and flow2). PE2 removes the FL. P1, P2, and P3 do not support traffic label for load balancing and they only forward data like a common P.
Figure 8-28 Traffic label application (P equipment does not support traffic label for load balancing)
P1 PE1 Flow 1 P3
PE2
Ingress P2
P5
Engress
P4 Flow 2
Payload Payload ETH ETH FL PW LSP ETH
Payload Payload ETH FL PW LSP ETH ETH FL PW LSP ETH
Payload Payload ETH FL PW LSP ETH ETH
8.1.6.6 PW Redundancy PW Redundancy Signaling Mechanism

Introduction of the PW protection mechanism will break the original model of 1-to-1 mapping between AC and PW in PWE3. To keep the original forwarding action, you must ensure that only one PW in the redundancy PW group is in the active state and other PWs are in the standby state. The LDP PW signaling (RFC4447) requires to use PW status TLV to transfer the PW forwarding status. PW status TLV can be carried by the label mapping message or notification message. PW status TLV is a 32-bit status code and each bit identifies a PW forwarding state. Based on this status code, PW redundancy introduces a new PW status code (0x00000020 - PW forwarding standby) to indicate that the PW is in the standby state currently.
8 Layer 2 VPN
Primary/Secondary and Active/Inactive

There are two couples of important concepts in PW redundancy and the detailed descriptions are as follows: l Primary/Secondary refers to the PW forwarding priority and is the PW configuration parameter. The primary PW is preferentially used to forward traffic and the secondary PW is used to protect primary PW. The primary PW is used to forward traffic when the state of the primary and secondary PWs is the same. Currently, only one secondary PW can be configured for each primary PW. l Active/Inactive refers to the PW forwarding status. It indicates the PW running status and is not the configuration parameter. Only the PW in the active state can be used to forward traffic. The local active or inactive state of a PW is determined by the local and remote signaling status and priority (configured primary/secondary) of the PW. Only the PW in the optimal state and with the highest priority can be selected as the active PW to forward traffic, and all other PWs are in the inactive state. PWs in the inactive state are not used to forward traffic but can be enabled to receive traffic (can be used only for VLL PW).
PW Redundancy Working Mode

The PW redundancy working mode is specified on PE that is configured with active and standby PWs. Master/Slave mode: In this mode, the local end determines the active or standby state of the PW and uses the signaling protocol to notify the remote end; the remote PE can sense the active or standby state. The active/ standby relationship on the PW side and the active/standby relationship on the AC side do not affect each other. Therefore, faults can be isolated between the PW side and the AC side. The MA5600T/MA5603T currently can function as a master in this mode. Independent mode: In this mode, the active or standby state of the local PW is determined by the negotiation result of the remote AC side; the remote end notifies the local end of the active or standby state. The protection switching due to faults on the AC side will cause the protection switching on the PW side. Therefore, faults cannot be isolated.
8.1.6.7 PW OAM (VCCV) VCCV Ping Application

Virtual Circuit connectivity verification (VCCV) is an end-to-end mechanism to detect and diagnose PW faults. To put it simply, VCCV is a control channel for transmitting connectivity verification messages between PW ingress and PW egress. VCCV ping is a tool for manually detecting the connectivity status of virtual circuits. It is implemented through extending LSP ping. VCCV defines a series of messages exchanged among PEs to verify PW connectivity. To ensure that the VCCV packet traverses the same path as the data packet in the PW, the VCCV packet must be encapsulated in the same encapsulation mode as the PW and must traverse the same tunnel as the PW packet.
8 Layer 2 VPN
VCCV ping can be used on the U-PE to detect PW connectivity, including detecting the connectivity of the static PW, dynamic PW, single-hop PW, and multi-hop PW. The MA5600T/ MA5603T supports single-hop-VCCV (SH-VCCV) ping and does not support multi-hop-VCCV (MH-VCCV) ping temporarily. Figure 8-29 shows the VCCV ping application. Figure 8-29 VCCV ping application
CE PE SPE P LSP2/PW2 PE CE
LSP1/PW1 LSP ping LSP label LSP ping LSP ping SH-VCCV
SH-VCCV PW label MH-VCCV
Principle
VCCV ping is implemented through the VCCV packet and the LSP ping packet therein carries the target FEC stack. Figure 8-30 describes the parameters of the VCCV packet. Figure 8-30 VCCV packet parameters
0x0c
0x04
CC types
CV types
CC Types indicates the control channel type. Figure 8-31 describes the CC for the VCCV function, which is defined in RFC5085. Figure 8-31 CC in the VCCV packet
Issue 01 (2011-10-30)
146
8 Layer 2 VPN
Type1: control word channel. Whether VCCV is performed depends on the control word (0001 or not). SH-VCCV and MH-VCCV are supported. If the PE supports control word, CC type1 is used preferentially. Type2: MPLS router alert channel. Whether VCCV is performed depends on a specific label value (label = 2). SH-VCCV is supported and MH-VCCV is not supported. Type3: maximum-hop channel. VCCV is performed if the TTL value of the inner label of MPLS is 1. SH-VCCV and MH-VCCV are supported. l CV Types indicates the connectivity verification type. Figure 8-32 describes the CV for the VCCV function, which is defined in RFC5085. The MA5600T/MA5603T supports only CV of the LSP ping type. Figure 8-32 CV in the VCCV packet
T-PE peers at both sides negotiate CC and CV capabilities during PW set-up, and then send the same CC and CV types used by VCCV ping as the negotiation result. If the PE supports control word, CC type1 is used preferentially. SH-VCCV and MH-VCCV are implemented through setting different inner PW label TTL values. Figure 8-33 shows the CC Type1 VCCV flow. Figure 8-33 CC Type1 MH-VCCV/SH-VCCV flow
U-PE VCCV CW (0001) TTL=255 MH-VCCV CC Tpye 1 S-PE S-PE U-PE
VCCV CW (0001) TTL=254
VCCV CW (0001) TTL=253 Trigger VCCV
SH-VCCV CC Tpye 1
VCCV CW (0001) TTL=1 Trigger VCCV
Issue 01 (2011-10-30)
147
8 Layer 2 VPN
Figure 8-34 shows the CC Type3 VCCV flow. Figure 8-34 CC Type3 MH-VCCV/SH-VCCV flow
U-PE VCCV No CW TTL=3 MH-VCCV CC Tpye 3 S-PE VCCV No CW TTL=2 S-PE U-PE
VCCV No CW TTL=1 Trigger VCCV
SH-VCCV CC Tpye 3
VCCV No CW TTL=1 Trigger VCCV
The U-PE and S-PE differ in processing the VCCV packet: l l l The S-PE pays attention to only the PW TTL value. If the PW TTL value is 1, VCCV is performed. The U-PE pays attention to not only CW (VCCV is performed if the first half-byte is 0001) but the PW TTL value (VCCV is performed if the PW TTL value is 1). If the U-PE initiates VCCV to the S-PE, a proper TTL value needs to be set, irrespective of whether CW is used.

Network Applications of TDM PWE3
For details on the corresponding clock solution of the TDM service, see 23.2 Clock and Time System. l Network application: converting the TDM PWE3 service or the native TDM service into the E1/STM-1 service for upstream transmission As shown in Figure 8-35, the mobile 2G base station is connected to the ONU through TDM E1. The ONU performs TDM PWE3 emulation, or the ONT encapsulates the TDM frame into the GPON GEM frame directly to transmit TDM service over the GPON network (native TDM). The OLT terminates the TDM PWE3 signals and transmits the signals to the upstream SDH network through the E1 or STM-1 port.
Issue 01 (2011-10-30)
148
8 Layer 2 VPN
Figure 8-35 Network application: converting the TDM PWE3 service into the E1/STM-1 service for upstream transmission
BTS N*E1 ONU OLT E1/STM-1 SDH TDM PWE3 Service stream E1/STM-1 BSC
TDM
Network application: converting the native TDM service into the TDM PWE3 service As shown in Figure 8-36, the mobile 2G base station is connected to the ONT through TDM E1. The ONT encapsulates the TDM frame into the GPON GEM frame directly to transmit TDM service over the GPON network (native TDM). The OLT coverts the native TDM packets into CESoP, and transmits service streams to the peer TDM PWE3 device (a PTN device in this example) through the PSN. In this way, the messages between the BTS and the BSC are transmitted over the PSN. Figure 8-36 Network application: converting the native TDM service into the TDM PWE3 service
BTS N*E1 PSN ONT OLT PTN N*E1 BSC
TDM
Native TDM
TDM PWE3(SAToP)
TDM
Service stream
Network Applications of ATM PWE3

l Network application: implementing PWE3 private line upstream transmission in ATM access As shown in Figure 8-37, when the MA5600T/MA5603T is connected to the ATM DSLAM or ADSL2+ modem, ATM private line service can be implemented between the MA5600T/MA5603T and the peer ATM BRAS through ATM PWE3 private line. The ATM PWE3 private line service is applicable to ATM network restructuring.
Issue 01 (2011-10-30)
149
8 Layer 2 VPN
Figure 8-37 Network application: implementing PWE3 private line upstream transmission in ATM access
Modem ADSL2+ GE STM-1 PSN ATM Access Node PWE3 Gateway
ATM PWE3 ATM DSLAM
Network Applications of ETH PWE3

l Network application: implementing PWE3 private line upstream transmission in FE/GE access As shown in Figure 8-38, the enterprise router is connected to the OLT through FE/GE. The OLT interconnects with the peer ETH PWE3 device of the enterprise through the ETH PWE3 private line to implement the ETH private line service. Figure 8-38 Network application: implementing PWE3 private line upstream transmission in FE/GE access
ONU FE/GE OLT GE PSN OLT ONU
ETH PWE3

Glossary
Term PE Explanation A PE is an edge router on the core network. It is connected to a CE and mainly implements the VPN service access. A PE maps and forwards packets from the private network to the public network tunnel, or from the public network tunnel to the private network. PEs can be classified as UPE and SPE.
Issue 01 (2011-10-30)
8 Layer 2 VPN
Term P device
Explanation A P device is a backbone device on the service provider's network and is not directly connected to a CE. The P device only needs to possess the basic MPLS forwarding capability, but need not maintain the VPN information.

Acronym/Abbreviation PWE3 Full Spelling Pseudo wire emulation edge-to-edge (a pointto-point L2VPN service provided on the public network). Pseudo wire (A bidirectional virtual connection between two PEs. It consists of two uni-directional MPLS VCs.) Multi-Protocol Label Switch Time division multiplexing Structure-agnostic transport over packet Circuit-Emulation Service over Packet Provider edge router (a router located on the edge of a backbone network) Ultimate provider edge (a PE located closer to the user side, mainly functioning as a VPN aggregation device for user access) PW switching point (A switching node PE in multi-hop PW. SPE does not exist in RSVP signaling.) Attachment circuit (An access link, a connection between CE and PE. It can be a physical interface or a virtual interface.) Control word Virtual circuit connectivity verification Multi-hop VCCV Single-hop VCCV Base transceiver station Base station controller
PW
MPLS TDM SAToP CESoP PE UPE
SPE
AC
CW VCCV MH-VCCV SH-VCCV BTS BSC
Issue 01 (2011-10-30)
151
8 Layer 2 VPN
Acronym/Abbreviation ECMP
Full Spelling Equal cost multiple path
8.2 Native TDM

In Native TDM, TDM frames are directly encapsulated to GPON GEM frames in TDMoGEM mode. This mode features simple encapsulation, small network cost, and guaranteed link quality.
8.2.1 Introduction
Definition
By using the standard 8 kHz (125m) frames, the GPON GTC layer is synchronous in nature. Therefore, GPON can support the TDM service. This is called Native TDM. In Native TDM, TDM frames are directly encapsulated to GPON GEM frames in TDMoGEM mode. This mode features simple encapsulation, small network cost, and guaranteed link quality.
Purpose
Currently, the circuit switched network is evolving to the packet switched network. During the deployment of the packet switched network, the method to provide traditional circuit switching service over the packet switched network must be taken into consideration. In a GPON network deployment, the traditional TDM service can be delivered over the PSTN network through the Native TDM mode.
l l l l l l Each TOPA board provides 16 E1 upstream ports or two STM-1 ports. Each TOPA board provides 2 STM-1 ports and supports processing the Native TDM service based on packet transmission. Up to 63 TDM service streams can be configured on each STM-1 upstream port. The STM-1 port supports 1+1 protection. The STM-1 port supports the system clock, line clock, and recovery clock. Each TOPA board supports two STM-1 ports, with each STM-1 port supporting creation of up to 63 TDM service virtual ports. Therefore, each TOPA board supports creation of up to 126 TDM service virtual ports. The 24-hour BER of the TDM service is 0. The delay of the TDM service transmission from the E1 port on the ONT to the upstream STM-1 port on the OLT must be shorter than 1.5 ms.
l l
8.2.3 Reference
The following lists the reference documents of Native TDM: l ITU-T G.984.1 General characteristics for Gigabit-capable Passive Optical Networks (GPON)
Issue 01 (2011-10-30)
8 Layer 2 VPN
l l l
ITU-T G.984.2 Gigabit-capable Passive Optical Networks (GPON): Physical Media Dependent (PMD) layer specification ITU-T G.984.3 Gigabit-capable Passive Optical Networks (GPON): Transmission convergence layer ITU-T G.984.4 Gigabit-capable Passive Optical Networks (GPON): ONT management and control interface specification
8.2.4 Availability
Hardware support
The Native TDM feature needs the cooperation between the TOPA board and the GPBC or GPBD board.
License support
The Native TDM feature is the basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Limitation
l l l The E1 ports of the ONU/ONT must support the Native TDM mode. The E1 service traffic is processed as the unstructured data stream in a unified way. The structured channel mode is not supported. The STM-1 port does not support the OC-3 mode.
8.2.5 Principle
Basic Principle
The MA5600T/MA5603T supports E1 and STM-1 upstream transmission mode. The following section uses E1 upstream transmission as an example.
NOTE
The application of STM-1 upstream transmission is similar to the application of E1 upstream transmission. The only difference lies in that different daughter boards are attached to the TOPA boards in two applications. When the TOPA board provides STM-1 ports, STM-1 frames are generated. One STM-1 frame can encapsulate and multiplex up to 63-channel E1 service signals (One STM-1 frame contains one VC4, one VC4 maps 63 VC12s, and one VC12 maps one-channel E1 service signal).
In the TDMoGEM mode, the TDM frame is directly encapsulated to the GPON GEM frame so that the TDM service can be transmitted in a GPON network. Figure 8-39 shows the basic principle of Native TDM.
Issue 01 (2011-10-30)
153
8 Layer 2 VPN
Figure 8-39 Basic principle of Native TDM

TDM byte buffer GEM frame PLI Input buffer PortID PTI HEC
Input of TDM TDM service
TDM data
Payload:TDM field
Poll each frame to confirm the sent bytes
Mapping of the TDM service to the GEM frames allows variation of the GEM frame length based on frequency offset of the TDM service. The length of the TDM field is specified by the PLI field. In the adaptation process of the TDM source, the input data enters a queue in the input buffer. When a frame arrives (namely for every 125 s) there, the multiplexing entity of the GEM frame records the number of bytes to be sent in the current GEM frame. In general, the PLI specifies a fixed byte count based on the TDM nominal rate. But it happens that the bytes larger or smaller than the fixed byte count are sent, which are reflected in the PLI field. The TDMoGEM mode does not distinguish whether it is a structured service such as the voice and PBX access services, or an un-structured service such as private line service. All services are handled as un-structured services. GPON access transparently delivers only the E1 service without performing the refined service processing. In other words, GPON access provides the long-haul E1 transmission. In general, the private line service has an independent clock, which is asynchronous with the GPON line clock. The jitter and frequency difference exist between the two clocks. Therefore, the E1 service traffic can be transmitted only after the E1 rate adjustment occurs at the ONU. The bit asynchronous mapping mode of SDH is adopted while the GPON line clock or system clock is used as the reference clock. Through the bit adjustment, the E1 service traffic is mapped to the payload section of the tributary unit to form a standard VC12 virtual channel, which is delivered in the GEM frame. At the receiver end, de-byte adjustment is adopted to recover the original clock and the E1 service traffic.
Application
Figure 8-40 shows the TDMoGEM network application. The E1 ports of the ONU/ONT access the TDM traffic from the base stations and enterprises. The ONU/ONT sends both the Ethernet traffic and the TDM traffic to the OLT. The OLT differentiates the Ethernet traffic and the TDM traffic, and sends the traffic to the IP network and the SDH network, respectively.
Issue 01 (2011-10-30)
154
8 Layer 2 VPN
Figure 8-40 Native TDM network application

Ethernet E1 Base station ONU OLT Ethernet E1 Business center ONU GPON E1 SDH
GPON
Ethernet
Ethernet ONU E1 Business center TDMoGEM

This topic provides the glossary, acronyms, and abbreviations of the Layer 2 tunnel emulation feature.
Glossary
None

Table 8-4 Acronyms and abbreviations of the Layer 2 Tunnel Emulation feature Acronym/Abbreviation PWE3 TDM SAToP CESoP MPLS LDP LSP
Issue 01 (2011-10-30)
Full Spelling Pseudo Wire Emulation Edge-to-Edge Time-Division Multiplexing Structure-Agnostic Transport over Packet Circuit-Emulation Service over Packet Multi-Protocol Label Switching Label Distribute Protocol Label Switching Path
155
8 Layer 2 VPN
Acronym/Abbreviation BTS BSC
Full Spelling Base Transceiver Station Base Station Controller
Issue 01 (2011-10-30)
156
9 Layer 2 Protocol Handling
9
About This Chapter
9.1 Overview
Layer 2 Protocol Handling
The Layer 2 protocol handling includes multiple features and also refers to link layer protocol management. This topic describes the features of Layer 2 protocol handling in details.
9.2 MAC Address Management This topic provides the definition, specifications, availability, and principle of the MAC address management feature. 9.3 1:1 VMAC VMAC means virtual MAC address. In 1:1 VMAC, the device replaces a single user MAC address with a unique virtual MAC address. The user MAC address and the VMAC of the device are in a 1:1 mapping. 9.4 N:1 VMAC VMAC means virtual MAC address. In N:1 VMAC, the device replaces a set of user MAC addresses with a unique virtual MAC address. The user MAC addresses and the VMAC of the device are in an N:1 mapping. 9.5 VLAN Management This topic provides the definition, specifications, reference standards and protocols, availability, and principle of the VLAN management feature. 9.6 VLAN Switching Policy This topic provides the definition, specifications, availability, and principle of the VLAN switching policy. 9.7 Forwarding Policy This topic provides the definition, specifications, availability, and principle of the forwarding policy feature. 9.8 Bridging With the bridging feature enabled on the MA5600T/MA5603T, the access users on the MA5600T/MA5603T can communicate with each other at Layer 2. 9.3.6 Glossary, Acronyms, and Abbreviations
Issue 01 (2011-10-30)
157
9.1 Overview
The Layer 2 protocol handling feature refers to the management of the link layer protocol, including the following sub features: MAC address management, VLAN management, traffic stream processing capability, forwarding policy, traffic classification policy, access user bridging.
9.2 MAC Address Management

This topic provides the definition, specifications, availability, and principle of the MAC address management feature.
9.2.1 Introduction
Definition
MAC address management is a basic Layer 2 management feature, including setting the MAC address aging time, limiting the number of dynamic MAC addresses (the number of the MAC addresses that can be learned), and setting the static MAC address.
Purpose
l Setting the MAC address aging time After the MAC address aging time is set, the system periodically checks a dynamic MAC address that is aged. If no packet carrying this source MAC address is transmitted or received one or two times of the aging time, the system deletes the MAC address from the MAC address table. l Limiting the number of dynamic MAC addresses (the number of the MAC addresses that can be learned) Manual configuration of the number of dynamic MAC addresses (the number of the MAC addresses that can be learned) is supported. When the number of learned MAC addresses reaches the maximum number, the user port does not learn new MAC addresses. l Setting the static MAC address To connect the system to a device with a specified MAC address through a port, configure a static MAC address. The system forwards data according to the static MAC address directly.
Benefits
Benefits to Carriers l l Limiting the number of dynamic MAC addresses can limit the number of the MAC addresses that enter the network and reduce the load of the network device. Setting the dynamic MAC address can prevent MAC address change.
Benefit to Subscribers After the static MAC of the service port is set and the maximum number of the MAC addresses that can be learned is set to 0, the port receives only the user data that carry the preset static
MAC address, and thus, the MAC address binding function is implemented. This improves the user security.
The specifications of the MAC address management feature are as follows: l l l The SCUB control board supports a maximum of 16K MAC addresses. The SCUL control board supports a maximum of 16K MAC addresses. When working with the H801M2XA daughter board, the SCUN control board supports a maximum of 512K MAC addresses. When working with other daughter boards, it supports a maximum of 32K MAC addresses. The SCUF control board supports a maximum of 32K MAC addresses. The GPBC/GPBD/ETHB board supports a maximum of 32K MAC addresses. The xDSL/OPFA board supports a maximum of 1K MAC addresses. Setting the maximum number of the MAC addresses learned based on the service virtual port The maximum number of MAC addresses learned of a PON service board: 1023 (1023 indicates no limitation. In this case, the number of learnable MAC addresses is limited by the size of the learnable MAC address table of the corresponding board.) The maximum number of MAC addresses learned of an xDSL or OPFA board: 255 (255 indicates no limitation. In this case, the number of learnable MAC addresses is limited by the size of the learnable MAC address table of the corresponding board.) l l l The maximum number of static MAC addresses of the system: 1024 Setting the aging time of the dynamic MAC address, ranging from 10s to 1000000s, default: 300s Setting no aging of the dynamic MAC address
l l l l
CAUTION
The MAC address table adopts the Hash algorithm, which may result in Hash collision. l When the SCUN control board is used, it is recommended that the maximum number of concurrent online users (MAC addresses) in the system not exceed 16K. l When the SCUF control board is used, it is recommended that the maximum number of concurrent online users (MAC addresses) in the system not exceed 16K. l When the SCUL control board is used, it is recommended that the maximum number of concurrent online users (MAC addresses) in the system not exceed 4K. l When the SCUB control board is used, it is recommended that the maximum number of concurrent online users (MAC addresses) in the system not exceed 4K. l For the GPBC/GPBD board, it is recommended that the maximum number of concurrent online users (MAC addresses) on each board not exceed 4K. l For the ETHB/OPGD board, it is recommended that the maximum number of concurrent online users (MAC addresses) on each board not exceed 8K. l For the xDSL/OPFA board, it is recommended that the maximum number of concurrent online users (MAC addresses) on each board not exceed 256.
Issue 01 (2011-10-30)
159
9.2.3 Availability
License Support
No license is required to access the corresponding service.
Version Support
9.2.4 Principle
Setting the MAC address aging time
l If the aging time is too short, the dynamic MAC address will be deleted too early. When the device receives a data packet from an unknown address, the device broadcasts this data packet to all the ports in a VLAN. Such unnecessary broadcast affects the operation performance of the system. If the aging time is too long, the device will be unable to update the MAC address table according to the network change. As a result, new MAC addresses cannot be learned and packets are broadcast because of unreachability to the destination address. Periodical aging of dynamic MAC addresses can release the MAC address resources and prevent the fault that new MAC addresses cannot be learned. The aging time takes effect to only the dynamic MAC address, but not to the static MAC address.
l l
Limiting the maximum number of MAC addresses that can be learned

l l Even if the number of dynamic MAC addresses learned by a service channel has reached the threshold, the static MAC addresses can be created manually for this service channel. After a static MAC address is manually created for a service port and the maximum number of dynamic MAC addresses that can be learned by the service port is set to 0, the port receives only the user data from the static MAC address. In this way, the MAC address binding function is implemented.
Setting the static MAC address

l The system overwrites the same dynamic MAC address, if any for the service virtual port or upstream port. The static MAC address cannot be created if the same static MAC address already exists in the system. A static MAC address cannot be included in an existing MAC address pool. Before configuring a static MAC address to a MAC address pool, run the display mac-pool command to check whether the MAC address pool contains the static MAC address to be configured.
Issue 01 (2011-10-30)
l l l
One upstream port that exists in different VLANs can be configured with the same static MAC address. The system supports only unicast MAC addresses, which cannot be the MAC address of the system. Either a static MAC address or a dynamic MAC address can be deleted.
9.3 1:1 VMAC

VMAC means virtual MAC address. In 1:1 VMAC, the device replaces a single user MAC address with a unique virtual MAC address. The user MAC address and the VMAC of the device are in a 1:1 mapping.
9.3.1 Introduction
Definition
VMAC is abbreviated from virtual MAC address. It means that the MA5600T/MA5603T replaces the source MAC address of a user terminal with a virtual MAC address. In 1:1 VMAC, the MA5600T/MA5603T replaces each user MAC address with a unique virtual MAC address.
Purpose
In the typical Layer 2 forwarding model, a device is identified by its MAC address. However, not all such devices are directly controlled by the operator, so their MAC addresses may not always be trustable. Certain network devices have been used to solve the problem of MAC address conflict, but this is only part of the problems. l l The uniqueness of a MAC address can be ensured only at the network element (NE) level but not at the network level. An NE can detect a conflicting MAC address but cannot tell an authorized user from an unauthorized user.
VMAC comes up as an ideal solution. VMAC enables the operator to replace the MAC addresses of user devices with pre-defined (controllable) MAC addresses. Adopting VMAC enhances the Layer 2 forwarding model in two aspects: l Security: Replacing the MAC addresses of user devices with operator-defined MAC addresses ensures the uniqueness of MAC addresses in an entire network. This in turn avoids the problems arising from MAC address conflict. l Measurability: By ensuring the uniqueness of the MAC addresses of an entire network, the operator can connect multiple DSLAMs and edge routers by using the same VLAN. In this way, the operator can expand the number of devices sharing the same subnet and therefore improve the allocation efficiency of the IP address pool.
Benefit
Benefits to carriers
Security is enhanced. Carriers can allocate trusted virtual MAC addresses to replace source MAC addresses of user terminals, so users with untrustable MAC addresses are denied access to the carriers' networks. This is an effective countermeasure to MAC spoofing. Users can be identified. The coding of a virtual MAC address can contain the user location or other information (such as the subrack ID/slot ID/port ID), so the user can be directly located in the carrier's network according to the MAC address.
Benefits to users This feature prevents MAC address conflicts and protects users from MAC address spoofing.
The specifications of the 1:1 VMAC feature are as follows: l l l l l l l l l l 1:1 VMAC is supported in PPPoE, PPPoA, and IPoE access. Each port supports a maximum of 32 VMACs in both PPPoE and IPoE access. The MA5600T/MA5603T supports 1:1 VMAC for a maximum of 8K ONTs, with each PON board supporting 1:1 VMAC for a maximum of 1K ONTs. A maximum of eight VMAC addresses are supported for each ONT. The maximum number of VMAC addresses for each ONT is configurable. The MA5600T/MA5603T supports a maximum of 64K GPON VMAC addresses, with each PON board supporting a maximum of 8K GPON VMAC addresses. The global-level VMAC switch and VLAN-level VMAC switch are supported. The VMAC mapping of only DHCP users is not lost after reset. The QinQ private line service does not support VMAC. LTM/LTR transparent transmission is supported. The MAC address in the Ethernet OAM LTM/LTR packet payload can also be replaced with a VMAC address. The MAC address in ARP, DHCP, and ND packet payloads can be replaced with a VMAC address.
9.3.3 Availability
License Support
The 1:1 VMAC feature is an optional feature of the MA5600T/MA5603T, and the corresponding service is controlled by the license.
Version Support
Table 9-2 lists the versions that support the 1:1 VMAC feature. Table 9-2 Base version required for the 1:1 VMAC feature in an IPv4 network Product MA5600T/MA5603T Version V800R006C02 and later versions
Issue 01 (2011-10-30)
162
Feature Dependency
The VLAN-based 1:1 VMAC feature is mutually exclusive with the VLAN-based N:1 VMAC feature. Cascading GEM ports do not support GPON 1:1 VMAC. Type C does not support GPON 1:1 VMAC.
Hardware Support
Boards supporting PPPoE/IPoE 1:1 VMAC: xDSL, H805GPBD, OPFA, and OPGD boards. Boards supporting PPPoA 1:1 VMAC: xDSL boards.
9.3.4 Feature Enhancement

Table 9-3 lists the new functions of 1:1 VMAC in the new versions. Table 9-3 New functions of 1:1 VMAC Version V800R010 New Function GPON 1:1 VMAC
9.3.5 Principle
1:1 VMAC in PPPoE/IPoE Access
The user source MAC address exists not only in the MAC header but also in the data field. The MA5600T/MA5603T replaces the Ethernet source MAC address in both the header and the data field of the Ethernet frame. Figure 9-1 Working process of 1:1 VMAC in PPPoE/IPoE access
User MAC U1 MAC U1 MAC B MAC B MAC U1 MAC U1 MAC V1 MAC address conversion MAC V1 MAC B MAC B MAC V1 MAC B MAC Vn MAC Vn MAC B MAC B MAC Vn Destination MAC address Source MAC address Remaining fields in the packet BRAS
MAC Un
Figure 9-1 shows the working process of the 1:1 VMAC supported in PPPoE and IPoE. The detailed conversion process is as follows:
MAC Un MAC B MAC B MAC Un
MAC Un
In the upstream direction: When receiving a new user MAC address (MAC U1), the MA5600T/MA5603T adds a mapping entry of the new user MAC address and the VMAC: MAC U1 maps MAC V1. When receiving a user MAC address that is already mapped to an allocated VMAC address, the MA5600T/MA5603T only overwrites the aging flag and uses the allocated VMAC. When receiving a user MAC address that is not mapped to an allocated VMAC and finding that the VMAC entries have reached the maximum, the MA5600T/ MA5603T determines that the MAC address fails to be learned and discards the user packet. When the user is automatically allocated a VMAC (MAC V1) by the system, the source MAC address (MAC U1) in the Ethernet packet header is replaced with the VMAC.
NOTE
The VMAC conversion rule also applies to control-layer protocol packets (ARP, ND, DHCP, and ETHOAM). The UMAC (MAC U1) in the payload of these packets also needs to be replaced with VMAC (MAC V1).
In the downstream direction: The destination MAC address in the Ethernet packet is the VMAC (MAC V1). The system uses VLAN+VMAC to query the ARL table and obtain the egress port information. Then, the system queries the VMAC table and replaces the VMAC with the UMAC (MAC U1).
NOTE
The VMAC conversion rule also applies to control-layer protocol packets (ARP, ND, DHCP, and ETHOAM). The VMAC (MAC V1) in the payload of these packets also needs to be replaced with UMAC (MAC U1).
VMAC addresses that are not used are released according to the MAC address aging mechanism.
1:1 VMAC Aging Mechanism

The 1:1 VMAC aging mechanism has two types, which can be selected through CLI configuration l Aging mechanism based on ARL table: According to the preset MAC address aging time, the system periodically checks a dynamic MAC address that is aged. If no packet carrying the corresponding VMAC is transmitted or received within the aging time, the system automatically releases the VMAC and the VMAC can be allocated to another user. l Aging mechanism based on DHCP or SLAAC: If the DHCP server receives the IP address release request from the DHCP client or does not receive the lease renewal request from the client within the lease time, the DHCP server releases the IP address. The corresponding user MAC address and VMAC are aged only after the IP address is released; if the IP address is not released, the corresponding user MAC address and VMAC are not aged.
Issue 01 (2011-10-30)
164
1:1 VMAC in PPPoA Access

Figure 9-2 Working process of 1:1 VMAC in PPPoA
PPPoA packet DATA PPP AAL ATM PVC Add VMAC DATA DATA IP PPP PPPoE IPoE Ethernet MAC V1 MAC B MAC V1 MAC B MAC V1 MAC B MAC Vn MAC B MAC Vn DATA PPP AAL ATM PVC PPPoA packet MAC B MAC Vn DATA DATA IP PPP IPoE PPPoE Ethernet Destination MAC address Source MAC address Remaining fields in the packet
BRAS
PPPoA terminal 1 Connected to the same board PPPoA terminal n
Delete VMAC
Figure 9-2 shows the working process of 1:1 VMAC supported in PPPoA. The detailed conversion process is as follows: l In the upstream direction: The MA5600T/MA5603T allocates a VMAC to each port according to the 1:1 VMAC address allocation rule. After receiving PPPoA packets, the system replaces the source MAC address of each PPPoA session with the VMAC (MAC Vn or MAC V1) of the user port, and then forwards the packets according to the normal PPPoA forwarding process. l In the downstream direction: Each PPPoA session adopts the VMAC (MAC Vn or MAC V1) as the destination MAC address. The system uses VLAN+VMAC to query the ARL table and obtains the egress port information. Then, the system forwards the packets according to the normal forwarding process. GPON does not support PPPoA encapsulation; therefore, GPON 1:1 VMAC is not covered.
1:1 VMAC Conversion Policy for Unicast, Multicast, and Broadcast Packets
For unicast packets: l In the upstream direction, 1:1 VMAC conversion applies only to the source MAC address of the unicast packets received by the MA5600T/MA5603T, and does not apply to the destination MAC address of the packets. In the downstream direction, 1:1 VMAC conversion applies only to the destination MAC address of the unicast packets received by the MA5600T/MA5603T, and does not apply to the source MAC address of the packets.
For multicast packets: 1:1 VMAC does not apply to the multicast packets of the MA5600T/ MA5603T in either the upstream or downstream direction. For broadcast packets:
Issue 01 (2011-10-30)
165
In the upstream direction, 1:1 VMAC conversion applies only to the source MAC address of the broadcast packets received by the MA5600T/MA5603T, and does not apply to the destination MAC address of the packets. In the downstream direction, the destination MAC address of the broadcast packets is the broadcast address FF and does not need to be converted; the source MAC address of the packet also do not need to be converted.
1:1 VMAC Format

The format of GPON 1:1 VMAC is different from that of other 1:1 VMAC. Table 9-4 describes the default format of GPON 1:1 VMAC and Table 9-5 describes the default format of other 1:1 VMAC. Table 9-4 GPON 1:1 VMAC format MAC Address 47-42 bits 41 bit Description Reserved bits, configurable through the CLI. Indicates whether the local MAC address is valid or the MAC address is assigned by an internal organization. Unicast address OLT ID configured by the user. ID of the GPON slot to which the user belongs. ID of the GPON port to which the user belongs. ID of the ONT to which the user belongs. Unique MAC address dynamically allocated by the OLT to the user.
40 bit 39-24 bits 23-18 bits 17-13 bits 12-3 bits 2-0 bits
Table 9-5 1:1 VMAC format MAC Address 47-42 bits 41-40 bits 39-21 bits 20-15 bits 14-6 bits 5-0 bits Description Reserved bits, configurable through the CLI. Fixed values (1 for bit 41 and 0 for bit 40). DSLAM ID configured by the user. ID of the slot to which the user belongs. ID of the port to which the user belongs. Unique MAC address allocated to the user.
Issue 01 (2011-10-30)
166

NOTE
To ensure the uniqueness of the MAC address, the DSLAM or OLT ID must be configured before the VMAC function of the VLAN is enabled. The uniqueness of the DSLAM or OLT ID needs to be ensured during the configuration; otherwise, two different DSLAMs or OLTs may be allocated the same VMAC.

Glossary
Table 9-6 Glossary of the terms related to the access user bridging feature Term User board S+C forwarding Description In this document, a user board refers to the board that provides users with the access service. In the S+C forwarding mode, Ethernet packets are forwarded according to the two-layer VLAN tags in the header. The external-layer VLAN tag is the S-tag and the internal-layer tag is the C-tag.

Table 9-7 Acronyms and abbreviations of the access user bridging feature Acronym/ Abbreviation SCUN Full Spelling Description The SCUN control board. It provides up to 24 10GE ports, and 4 GE ports on the front panel. It provides 8 GE ports and 2 10GE ports on the front panel. Null Null Null Null Null Null Null
Super Control Unit Board VerN
SPU OLT ONU ONT VMAC ARL LTM LTR
Service Process Unit Optical Line Terminal Optical Network Unit Optical Network Terminal Virtual MAC Address Resolution List Linktrace Message Linktrace Reply
Issue 01 (2011-10-30)
167
9.4 N:1 VMAC

VMAC means virtual MAC address. In N:1 VMAC, the device replaces a set of user MAC addresses with a unique virtual MAC address. The user MAC addresses and the VMAC of the device are in an N:1 mapping.
9.4.1 Introduction
Definition
VMAC is abbreviated from virtual MAC address. It means that the MA5600T/MA5603T replaces the source MAC address of a user terminal with a virtual MAC address. N:1 VMAC is also called single-MAC. In N:1 VMAC, a set of user MAC addresses are replaced with a unique virtual MAC address. When it comes to the MA5600T/MA5603T, all users of each service board are mapped to one virtual MAC address.
Purpose
In the typical Layer 2 forwarding model, a device is identified by its MAC address. However, not all such devices are directly controlled by the operator, so their MAC addresses may not always be trustable. Certain network devices have been used to solve the problem of MAC address conflict, but this is only part of the problems. l l The uniqueness of a MAC address can be guaranteed only at the network element (NE) level but not at the network level. An NE can detect conflicting MAC addresses but cannot differentiate an authorized user from an unauthorized user.
VMAC comes up as an ideal solution. VMAC enables the operator to replace the MAC addresses of devices with pre-defined (controllable) MAC addresses. Adopting VMAC enhances the Layer 2 forwarding model in two aspects: l Security: Replacing the MAC addresses of devices with operator-defined MAC addresses ensures the uniqueness of MAC addresses in an entire network. This in turn avoids the problems arising from MAC address conflict. l Measurability: By ensuring the uniqueness of the MAC addresses in an entire network, the operator can connect multiple DSLAMs and edge routers by using the same VLAN. In this way, the operator can expand the number of devices sharing the same subnet and thus improve the allocation efficiency of the IP address pool. In addition, since N:1 VMAC allows multiple user MAC addresses to be replaced by one virtual MAC address, this also solved the problem of insufficient MAC address entries on the carriers' upper-layer aggregation devices.
Benefit
Benefits to carriers
Security is enhanced. Users with untrusted MAC addresses are denied the access to carriers' networks; instead, users access the networks with the trusted virtual MAC addresses allocated by carriers' equipment. MAC address space is saved. In an Layer 2 network with a large number of users, the MAC address space of the equipment usually bottlenecks the network. The N:1 VMAC feature greatly saves the MAC address space.
Benefits to users This feature prevents MAC address conflicts and protects users from MAC address spoofing.
The specifications of the N:1 VMAC feature are as follows: l l l l Supports N:1 VMAC in PPPoE access. Supports up to 1K PPPoE users. Supports N:1 VMAC in PPPoA access. Supports up to 1K PPPoA users. Supports the global-level VMAC switch; Supports the VLAN-level PPPoE and PPPoA N: 1 VMAC feature. The QinQ private line service does not support the N:1 VMAC function.
9.4.3 Availability
License Support
N:1 VMAC is a basic feature of the MA5600T/MA5603T. Therefore, the corresponding service is provided without a license.
Version Support
Table 9-8 lists the versions that support the N:1 VMAC feature. Table 9-8 Base version required for the N:1 VMAC feature Product MA5600T/MA5603T Version V800R006C02 and later versions
Feature Dependency
PPPoE N:1 VMAC and anti-MAC spoofing are mutually exclusive. When the two features are enabled at the same time, only PPPoE N:1 VMAC takes effect.
Hardware Support
Boards supporting N:1 VMAC: all xDSL boards, GPON boards, the OPFA board, and OPGD board.
Issue 01 (2011-10-30)
169
9.4.4 Principle
N:1 VMAC in PPPoE Access
The user source MAC address exists not only in the MAC header but also in the data field. The MA5600T/MA5603T replaces the Ethernet source MAC address in both the header and the data field of the Ethernet frame. Figure 9-3 Working process of N:1 VMAC
User MAC U1 MAC U1 MAC B MAC B MAC U1 MAC Un MAC B MAC B MAC Un MAC Un MAC address conversion MAC U1 BRAS
MAC V
MAC V MAC B MAC B MAC V
MAC Un MAC U1
MAC B
Figure 9-3 shows the working process of the N:1 VMAC supported in PPPoE. The detailed conversion process is as follows: l In the upstream direction: The MA5600T/MA5603T replaces all the received user MAC addresses (MAC U1MAC Un) of the same board with the MAC address (MAC V) of this board. For the PON port protect group in xPON: 1. 2. Configure a MAC address pool used for N:1 VMAC. The system automatically allocates an idle MAC address from the MAC address pool to the user MAC addresses received. Each PON port protect group uses the same MAC address. The system replaces the user MAC addresses (MAC U1-MAC Un) with the allocated MAC address (MAC V).
MAC Un Destination MAC address Source MAC address Remaining fields in the packet
MAC V
3. l
In the downstream direction: The system forwards PPPoE packets according to the PPPoE session ID, and replaces the MAC address (MAC V) of the board with the user MAC addresses (MAC U1-MAC Un). For the PON port protect group in xPON: According to the MAC address mapping entry, the system replaces the user MAC addresses (MAC U1-MAC Un) with the allocated VMAC (MAC V).
The conversion principle of VMAC also applies to the ARP protocol. The MAC address in the packet payload also needs to be replaced with a VMAC.
Issue 01 (2011-10-30)
170
N:1 VMAC in PPPoA Access

Figure 9-4 Working process of N:1 VMAC in PPPoA
PPPoA packet DATA PPP AAL ATM PVC Add VMAC DATA DATA IP PPP PPPoE IPoE Ethernet BRAS
PPPoA terminal
Connected to the same board PPPoA terminal DATA PPP AAL ATM PVC PPPoA packet
MAC V1 MAC B MAC V1 MAC B MAC V1 DATA DATA DATA IP PPP PPPoE IPoE Ethernet
MAC B
Delete VMAC
Destination MAC address Source MAC address Remaining fields in the packet
Figure 9-4 shows the working process of the N:1 VMAC supported in PPPoA access. The detailed conversion process is as follows: l In the upstream direction: The MA5600T/MA5603T allocates a MAC address to each board according to the N:1 MAC address allocation rules. After receiving PPPoA packets, the system replaces the source MAC addresses of all PPPoA sessions of the same board with the MAC address (MAC V1) of the board. Then, the system forwards the PPPoA packets according to the normal forwarding process. l In the downstream direction: All PPPoA sessions of the same board adopt the MAC address (MAC V1) of the board as the destination MAC address, and PPPoA packets are forwarded according to the session ID.
N:1 VMAC Conversion Not Applicable to Multicast and Broadcast Packets

N:1 VMAC is used to replace only the MAC addresses in the unicast packets received by the MA5600T/MA5603T and the legal user MAC addresses, and is not used to replace the other legal MAC addresses (such as in multicast and broadcast packets).
N:1 VMAC Allocation Rules

The MA5600T/MA5603T allocates a MAC address to each board according to to certain allocation rules. The MAC addresses corresponding to the N:1 VMAC of the same board all refer to the MAC address of the board. Table 9-9 shows the rules for generating the N:1 VMAC. Table 9-9 Rules for generating the N:1 VMAC Slot Slot < Control board slot Generation Formula Board MAC address = System bridge MAC address + 8 + Slot ID
171
Issue 01 (2011-10-30)
Slot Slot > Control board slot
Generation Formula Board MAC address = System bridge MAC address + 8 + Slot ID - 2
9.5 VLAN Management

This topic provides the definition, specifications, reference standards and protocols, availability, and principle of the VLAN management feature.
9.5.1 VLAN Overview

Definition
Virtual local area network (VLAN) is a technology used for logically grouping devices in the same LAN into different subnets in order to form virtual workgroups. VLAN is a basic technology that is widely applied to various access modes and services, such as multicast, triple play, wholesale, and private line services. The IEEE issued the 802.1q protocol for standardizing VLAN implementations in 1998, and revised the draft in 2003 and 2005. The IEEE issued the 802.1ad protocol for standardizing VLAN implementations in 2005.
Purpose
The VLAN management feature facilitates carriers' service planning. l The standard VLAN is primarily used for subtending. The MA5600T/MA5603T supports the Ethernet subtending networking. Several access devices at different levels can be subtended through the GE/FE ports, which can expand the network coverage and address the requirements for large access capacity. The smart VLAN is primarily used for saving the VLAN resources of the system or isolating users. The QinQ VLAN is primarily used for transparently transmitting private network VLAN tags to implement the Layer 2 VPN application. The stacking VLAN can identify users and services. In some scenarios, certain BRASs need to authenticate two VLAN tags. Therefore, the packets that are transmitted to the upstream BRAS must carry two VLAN tags. In this case, it is required that the device supports the stacking VLAN.
l l l
Packet Format
To learn more about VLAN processing, see the differences between untagged, 802.1q, and QinQ packet formats, as shown in Figure 9-5.
Issue 01 (2011-10-30)
172
Figure 9-5 Differences between untagged, 802.1q, and QinQ packet formats
Untagged Dest Addr 6 Dest Addr 6 Dest Addr 6 Src Addr 6 Src Addr 6 Src Addr 6 Length Type 2 Data 0-1500 Bytes FCS 4 Length Type 2 Data 0-1500 Bytes
802.1Q Encapsulation EType 2 Tag 2 FCS 4 Length Type 2 Data 0-1500 Bytes
Q-in-Q Encapsulation EType 2 Tag 2 EType 2 Tag 2 FCS 4
0x8100
Priority
CFI
VLAN ID
The specifications of the VLAN management feature are as follows: l l l l l l Smart VLAN, MUX VLAN, and standard VLAN 4K VLANs for the MA5600T/MA5603T. The VLAN ID ranges from 2 to 4093. VLAN planning based on the port QinQ VLAN and VLAN stacking Configuration and query of the start reserved VLAN. The consecutive 15 VLANs starting from the start reserved VLAN and VLAN 4094 are the reserved VLANs. In a VLAN profile, the following parameters can be set: anti-MAC spoofing; anti-IP spoofing, BPDU transparent transmission, RIP transparent transmission, VTP-CDP transparent transmission, DHCP option 82, PITP, the mode of forwarding packets, and the policy of forwarding packets. 256 VLAN profiles for the MA5600T/MA5603T.

The following lists the reference standards and protocols of this feature: l l l IEEE 802.1q: IEEE standards for Local and metropolitan area networks-Virtual Bridged Local Area Networks IEEE P802.1ad: Virtual Bridged Local Area Networks Amendment 4: Provider Bridges RFC3069: VLAN Aggregation for Efficient IP Address Allocation
9.5.4 Availability
Related NEs
This feature is a basic feature of the MA5600T/MA5603T and is not related to any other NE.
License Support
The attribute of a VLAN can be changed to stacking only when the VLAN stacking authority status is Permit.
Version Support
Feature Dependency
l QinQ VLAN A QinQ VLAN does not support the creation of a BTV user. A QinQ VLAN does not support VLAN interface. A QinQ VLAN does not support Anti IP spoofing. A QinQ VLAN does not support Anti MAC spoofing. A QinQ VLAN does not support SMAC. A QinQ VLAN does not support VMAC. A QinQ VLAN will cause packets without independent switch control to be transparently transmitted. l VLAN profile When a VLAN profile is bound to a QinQ VLAN, both the anti IP spoofing and anti MAC spoofing functions are unavailable. In a VLAN profile, the SVLAN+CVLAN forwarding and anti MAC spoofing functions cannot be enabled at the same time. When a VLAN profile is bound to a VLAN, the BPDU transparent transmission can be enabled only when the VLAN is a QinQ VLAN. When a VLAN profile is bound to a VLAN, the mode of forwarding packets cannot be set to the SVLAN+CVLAN forwarding mode when the VLAN is a common VLAN.
9.5.5 Types of VLAN

Four Types of VLAN
l Standard VLAN A standard VLAN is a VLAN that contains multiple interconnected standard Ethernet ports. All the ports in a standard VLAN are logically equal. The Ethernet ports in a standard VLAN can communicate with each other. An Ethernet port in a standard VLAN is isolated from an Ethernet port in another standard VLAN. l Smart VLAN A smart VLAN is a VLAN that contains upstream ports and service ports.
A smart VLAN can serve multiple access users, thus saving VLAN resources. A smart VLAN can contain multiple upstream ports and multiple service ports. The service ports in a smart VLAN are isolated from each other. l MUX VLAN A MUX VLAN is a VLAN that contains upstream ports and one service port. One MUX VLAN can contain multiple upstream ports but only one service port. A service port in a MUX VLAN is isolated from a service port in another MUX VLAN. One-to-one mapping can be set up between a MUX VLAN and an access user. Therefore, a MUX VLAN can uniquely identify an access user. l Super VLAN The concept of super VLAN is proposed to save IP address resources, and it is an Layer 3-based VLAN. A super VLAN is formed by aggregating multiple sub VLANs. Through the Layer 3 interface of the super VLAN, services of different sub VLANs can be forwarded at Layer 3. In this way, the usage efficiency of IP addresses is improved. A sub VLAN can be a smart VLAN or MUX VLAN but cannot be a QinQ VLAN or stacking VLAN. Different sub VLANs in a super VLAN are isolated at Layer 2, but they can communicate with each other through the Address Resolution Protocol (ARP) proxy.
Limitation of VLAN
l Standard VLAN If a VLAN contains an upstream port, delete the upstream port before deleting the VLAN. If a VLAN contains an Layer 3 interface, delete the interface before deleting the VLAN. l Smart VLAN If an Layer 3 interface has been created for a VLAN, delete the Layer 3 interface before deleting the VLAN. If a VLAN already contains an upstream port, delete the upstream port before deleting the VLAN. If a service port has been created for a VLAN, delete the service port before deleting the VLAN. The smart VLAN is a special type of VLAN. Besides the characteristics of the standard VLAN, the smart VLAN has the following characteristics: In a smart VLAN, the ports are of unequal status, that is, the ports in a smart VLAN are divided into upstream ports and service ports. The service ports in a smart VLAN are isolated from each other. The upstream ports in a smart VLAN can communicate with each other. A service port and upstream port in a smart VLAN can communicate with each other. The broadcast domain of each port in a standard VLAN covers all the ports in the VLAN. The broadcast domain of the upstream port in a smart VLAN covers all the ports in the VLAN. The broadcast domain of the service port, however, covers only the upstream ports in the VLAN. l
Issue 01 (2011-10-30)
MUX VLAN
If an Layer 3 interface has been created for a VLAN, delete the Layer 3 interface before deleting the VLAN. If a VLAN contains an upstream port, delete the upstream port before deleting the VLAN. If a service port has been created for a VLAN, delete the service port before deleting the VLAN.
9.5.6 VLAN Attribute

QinQ VLAN
Figure 9-6 shows QinQ VLAN service processing. Figure 9-6 QinQ VLAN service processing
VLAN 3 VLAN 2
L2/L3
L2/L3
Access Node
VLAN 3
VLAN 1
Access Node Modem VLAN 2
Modem VLAN 2 L2 VLAN 1 L2
User 1
User 3
User 4
User 2
Service flow of User 3 and User 4 Service flow of User 1 and User 2
The access node can implement communication between the users in one private network (VLAN 1 or VLAN 2) that is located in different regions through a QinQ VLAN. The service packets of the users are processed as follows: 1. 2. 3. 4. The PC user transmits untagged packets in the upstream direction. The Layer 2 LAN switch adds the private network VLAN tag (VLAN 1 or VLAN 2) to the packets of the PC user and transmits them to the access node in the upstream direction. The access node adds the public network VLAN tag (VLAN 3) to the packets and transmits them to the upper-layer network. The upper-layer network device transmits the packets according to the public network VLAN tag (VLAN 3).
Issue 01 (2011-10-30)
5. 6.
The peer access node removes the public network VLAN tag (VLAN 3) after receiving the packets, and transmits them to the LAN switch on the same side. The LAN switch identifies and removes the private network VLAN tag (VLAN 1 or VLAN 2), and forwards the untagged packets to the users in the private network VLAN.
As described in the preceding section, communication between user 1 and user 2 in VLAN 2 or communication between user 3 and user 4 in VLAN 1 is implemented through the QinQ VLAN.
VLAN Stacking
If VLAN stacking is used for increasing the VLAN quantity or identifying users, the cooperation of the BRAS is required. If VLAN stacking is used for providing the private line wholesale service, the upper-layer network must work in the Layer 2 mode and packets are forwarded according to VLAN+MAC directly. Figure 9-7 VLAN stacking service processing
ISP 1 MAN SP VLAN 1 C VLAN 1 L2/L3 SP VLAN 1 C VLAN 2 SP VLAN 2 SP VLAN 2
ISP 2
C VLAN 1 C VLAN 2
Modem
Access Node
Modem
Enterprise A
Enterprise B
Enterprise A User 1 to ISP1 Enterprise A User 2 to ISP1 Enterprise B User 1 to ISP2 Enterprise B User 2 to ISP2
The users of enterprise A are connected to ISP 1 through the access node by using a stacking VLAN and the users of enterprise B are connected to ISP 2 through the access node by using another stacking VLAN. The service packets of the users are processed as follows: 1. 2. The user transmits untagged packets in the upstream direction. The packets then reach the access node through the modem. The access node adds two VLAN tags to the untagged user packets. The users belonging to different ISPs map different outer SP VLANs.
Issue 01 (2011-10-30)
l The outer VLAN tag that is added to the user packets of enterprise A is SP VLAN 1 and the inner VLAN tag is the tag of the corresponding customer VLAN. l The outer VLAN tag that is added to the user packets of enterprise B is SP VLAN 2 and the inner VLAN tag is the tag of the corresponding customer VLAN. 3. 4. The exchange MAN device forwards packets to different ISPs according to the SP VLAN. After receiving the user packets, ISP 1 and ISP 2 remove the outer SP VLAN tag, and differentiate users according to inner customer VLAN tags.
Common VLAN
Common is the default attribute of a VLAN. A common VLAN does not contain the attribute of QinQ or stacking. A common VLAN can serve as a common Layer 2 VLAN or be used to create an Layer 3 interface for Layer 3 forwarding.
9.5.7 VLAN Processing

VLAN 802.1p Priority
When transmitting protocol packets through the CPU, the device fills the VLAN 802.1p priority in the packets. After receiving the packets, the peer device processes the packets according to their 802.1p priority. The packets of a higher priority are processed with precedence.
VLAN Configuration of a Port

In this context, VLANs are formed based on the ports on a network device. That is, different ports belong to different VLANs. To transmit user packets carrying a VLAN tag through an upstream port, the upstream port must be added to the VLAN first. After the upstream port is added to the VLAN, packets carrying this VLAN tag can be transmitted upstream through the port. A port can be added to multiple VLANs, and a VLAN can contain multiple ports.
Native VLAN of a Port

A native VLAN can be configured on an Ethernet port to determine whether a packet transmitted upstream through this port carries a VLAN tag. After the native VLAN of the Ethernet port is configured successfully, l l l If the VLAN ID of the Ethernet port is the same as its native VLAN ID, the packet transmitted upstream through the Ethernet port does not carry any VLAN tag (untagged). If the VLAN ID of the Ethernet port is different from its native VLAN ID, the packet transmitted upstream through the Ethernet port carries the VLAN tag. When receiving an untagged packet, the Ethernet port attaches the native VLAN tag to the packet before transmitting it.
Ethernet Protocol Types of the Inner and Outer VLAN Tags

The inner and outer VLAN tags of a packet do not adopt the standard 802.1q protocol. Therefore, for successful interoperation between Huawei devices and other vendors' devices, the Ethernet protocol types of the inner and outer VLAN tags on the interoperating devices must be the same. After the inner and outer Ethernet protocol types supported by VLAN stacking are set successfully, the inner and outer Ethernet protocol types of the packets captured by the upperlayer device should be the same as the preset Ethernet protocol types.
Ethernet Protocol Type of the Outer VLAN Tag of a Specified Port

Currently, only the H801SPUA board supports this feature. In practice, a port may be leased to a content provider (CP) to implement the wholesale service. In this case, the Ethernet protocol type of the outer VLAN tag of the packets transmitted from the port needs to be configured the same as that of the peer device, so as to meet the network requirements of the CP. The outer Ethernet protocol type of a port can be configured to 802.1q or 802.1ad. The value of 802.1q is invariably 0x8100; the value of 802.1ad is configurable but cannot be a value that has been adopted by other standard protocols. The default outer Ethernet protocol type of a port is 802.1q, which takes effect on all traffic streams on the port. 802.1ad takes effect only on the two-tagged switch-oriented and connection-oriented traffic streams on the port.
VLAN Service Profile

A VLAN service profile can be used to implement VLAN-level control on features such as VLAN forwarding mode, VLAN-based transparent transmission of BPDUs, SVLAN+CVLAN forwarding, and MAC address learning of the control board. These features also have their own configuration control switches. According to the principle of controlling services based on VLAN, when a VLAN is bound to a VLAN service profile, a feature is controlled by the VLANlevel control switch configured in the VLAN service profile; when a VLAN is not bound to a VLAN service profile, a feature is controlled by its own configuration control switch.
9.5.8 VLAN Aggregation

The super VLAN is an Layer-3-based VLAN. A super VLAN can contain multiple sub VLANs. Through ARP proxy, sub VLANs in a super VLAN can communicate at Layer 3. VLAN aggregation can implement Layer 3 interoperation and save IP addresses. A super VLAN needs to be configured with sub VLANs. A sub VLAN can be added to a specified super VLAN. A sub VLAN can be either a smart VLAN or MUX VLAN only and its attribute must be common. Figure 9-8 illustrates VLAN aggregation. When a super VLAN is used to aggregate multiple VLANs, ports in these VLANs can communicate with each other. If these VLANs are not aggregated, ports in these VLANs cannot communicate with each other. Figure 9-8 VLAN aggregation
Super VLAN 1
Su VL b AN 1
b Su N A L V 2
VLAN1
VLAN2
PC A
PC B
PC A
PC C
PC B
PC D
Issue 01 (2011-10-30)
179
9.5.9 Special Applications of VLANs

Reserved VLANs
The range of reserved VLANs in the system is configurable. After reserved VLANs are changed, the range of reserved VLANs is also changed. Currently, only consecutive reserved VLANs (for example, VLANs 3-18) are supported, and discontinuous reserved VLANs (for example, VLANs 3, 10, and 100) are not supported. The configuration of reserved VLANs takes effect only after the corresponding data is saved and the device is restarted. After reserved VLANs are changed, the system does not allow other services to use the VLANs that are taking effect currently or will take effect after system restarting. If the start reserved VLAN is not configured, the system uses VLAN 4079 as the start reserved VLAN and the 15 VLANs starting from VLAN 4079 as reserved VLANs by default. That is, reserved VLANs are VLANs 4079-4093. The configurable range of the start reserved VLAN is VLANs 2-4079. After the user configures a start reserved VLAN within this range, the system automatically uses the 15 VLANs starting from the configured VLAN as reserved VLANs. VLANs 4094 and 4095 are fixedly reserved, and VLAN 1 is the native VLAN. Therefore, these three VLANs cannot be configured as reserved VLANs.
VLAN-based Traffic Statistics Collection

Traffic statistics of a specified VLAN can be collected so that a user can learn about the network traffic condition. Currently, VLAN-based traffic statistics can be collected in two modes: service-board-based mode and ACL-based mode. l In the service-board-based mode, traffic statistics collection can be performed on the service ports in the VLAN or all VLANs in the system but cannot be performed on the standard ports in the VLAN. In the ACL-based mode, traffic statistics collection can be performed on the service ports and standard ports in the VLAN but can be performed on only a maximum of 64 VLANs concurrently.
9.6 VLAN Switching Policy

This topic provides the definition, specifications, availability, and principle of the VLAN switching policy.
9.6.1 Introduction
Definition
VLAN switching refers to switching from the user-side VLAN to the network-side VLAN.
Issue 01 (2011-10-30)
180
Purpose
VLAN planning is a composition of network planning. Users or services are identified by VLANs in flexible manners. Flexible VLAN switching policies facilitate the network planning of carriers.
The MA5600T/MA5603T supports the following specifications of the VLAN switching feature: l l l l l l l l Adding the S-VLAN tag to user untagged packets Adding the S-VLAN tag+C-VLAN tag to user untagged packets Switching one VLAN tag 1:1 or N:1 VLAN switching for the user packets carrying a VLAN tag Switching C-VLAN tag to S-VLAN tag+C-VLAN tag Switching C-VLAN tag to port ID+S-VLAN tag+C-VLAN tag Switching dual VLAN tags (switching S-VLAN tag+C-VLAN tag to S-VLAN' tag+CVLAN' tag) Transparent transmission of a VLAN tag
9.6.3 Availability
License Support
Version Support
Miscellaneous
Transparent transmission traffic streams must not carry the ID of the VLAN that contains the upstream port of the device.
NOTE
Transparent service-ports refer to the service-ports whose type is specified as transparent during creation. Protocol packets can be transparently transmitted through transparent service-ports.
9.6.4 VLAN Tag Transforming of Traffic Streams

Overview of VLAN Tag Transforming
After traffic classification is performed on packets, the VLAN tags of the packets need to be transformed. For details, see Figure 9-9.
Figure 9-9 VLAN tag transforming of traffic streams

Message Add Transparent Translate
If a packet matches a traffic rule, the device adds a VLAN tag to the packet or switches the VLAN tag of the packet according to the rule. If the packet does not match any traffic rule, the packet is dropped. Table 9-12 provides more details on VLAN tag transforming. Table 9-12 VLAN tag transforming modes VLAN Tag Transforming Mode Add Description Adds an SVLAN tag to the traffic stream transmitted from the user side to upstream. It is applicable to: l QinQ VLAN: implemented by default. l Common VLAN: implemented on single service. l Common VLAN: implemented on traffic streams classified by EtherType. l Common VLAN: implemented on untagged traffic streams. l Other all traffic streams (Any traffic stream classified by CVLAN). l VLAN range traffic streams.
Traffic Classification
VLAN Switching
Translate and Add Add Double Translate Double Translate and Remove Remove Remove Double QoS Handling Sending
Issue 01 (2011-10-30)
182
VLAN Tag Transforming Mode Transparent
Description Directly uses the CVLAN tag carried in the traffic stream as the SVLAN tag for upstream transmission. In this case, the SVLAN ID of the traffic stream must be the same as the CVLAN ID. It is applicable to: l Traffic streams created on subtending GEM ports. l Traffic streams tagged as QinQ and specified to be processed in the transparent mode.
Translate
Translates the CVLAN tag of the traffic stream into the SVLAN tag. It is applicable to: l Traffic streams tagged with a specified CVLAN, VLAN+802.1p priority, or VLAN+EtherType, and with the common SVLAN attribute. The CVLAN ranges from 1 to 4095 or is 0 (priority-tagged). l Traffic streams tagged as QinQ and specified to be processed in the translate mode.
TranslateAndAdd
Translates the CVLAN tag of the traffic stream and adds an SVLAN tag to the traffic stream. That is, the traffic stream goes upstream carrying two VLAN tags (SVLAN +CVLAN'). It is applicable to: l Traffic streams tagged with a specified CVLAN, VLAN+802.1p priority, or VLAN+EtherType, and with the stacking SVLAN attribute. The CVLAN ranges from 1 to 4095 or is 0 (priority-tagged). l Traffic streams tagged as QinQ and specified to be processed in the TranslateAndAdd mode.
AddDouble
Adds two VLAN tags (SVLAN+CVLAN) to the traffic stream for upstream transmission. It is applicable to: l Single-service traffic streams or traffic streams classified by EtherType, with the stacking SVLAN attribute. l Untagged traffic streams with the stacking SVLAN attribute; traffic streams tagged as QinQ and specified to be processed in the AddDouble mode.
Issue 01 (2011-10-30)
183
VLAN Tag Transforming Mode TranslateDouble
Description Translates the two VLAN tags of the traffic stream, that is, translates SVLAN+CVLAN to SVLAN'+CVLAN'. It is applicable to: l Traffic streams classified by SVLAN +CVLAN, with the stacking SVLAN attribute. l Traffic streams classified by SVLAN +CVLAN, with the QinQ SVLAN attribute and specified to be processed in the TranslateDouble mode.
NOTE Currently only the SPUA and OPGD boards support TranslateDouble.
TranslateAndRemove
Translates the SVLAN tag and removes the CVLAN tag of the traffic stream, that is, transforms SVLAN+CVLAN to SVLAN'. It is applicable to: l Traffic streams classified by SVLAN +CVLAN, with the common SVLAN attribute. l Traffic streams classified by SVLAN +CVLAN, with the QinQ SVLAN attribute. For this type of traffic stream, TranslateAndRemove is performed by default.
NOTE Currently only the SPUA and OPGD boards support TranslateAndRemove.
Remove
A unique VLAN tag transforming mode for the connection-oriented traffic stream. In this mode, the traffic stream carries one VLAN tag when arriving from the destination end, and has its VLAN tag removed when transmitted from the source end. Hence, the traffic stream is finally untagged. A unique VLAN tag transforming mode for the connection-oriented traffic stream. In this mode, the traffic stream carries two VLAN tags (SVLAN+CVLAN) when arriving from the destination end, and has its VLAN tags removed when transmitted from the source end. Hence, the traffic stream is finally untagged.
RemoveDouble
Issue 01 (2011-10-30)
184
Setting VLAN Tag Transforming Mode

During the creation of a traffic stream, the VLAN tag transforming mode can be set. If a mode is not specified, the system automatically determines the VLAN tag transforming mode according to the VLAN type, traffic classification type, and traffic classification parameters. Traffic streams tagged as QinQ (generally for the service of commercial users) can be configured with different VLAN tag transforming modes. Traffic streams with the common or stacking VLAN attribute support only fixed VLAN tag transforming modes; if a mode is to be specified, it must be the same as the value calculated by the system. Assuming the SVLAN attribute is QinQ, Table 9-13 lists the default and configurable VLAN tag transforming modes of switch-oriented traffic streams and the tag processing policies for upstream packets. Table 9-13 VLAN tag transforming mode (1) Traffic Classification Type Single service Traffic Classification Parameter None (Any) Default Transforming Mode Add Configurable Transforming Mode Add AddDouble By EtherType PPPoE Add Add AddDouble IPoE Add Add AddDouble By VLAN C-VLAN: 1-4095 Add Add AddDouble Transparent Translate TranslateAndA dd priority-tagged Add Add Tag Processing Policies Any -> S-tag +Any Any -> S-tag +C-tag+Any Any -> S-tag +Any Any -> S-tag +C-tag+Any Any -> S-tag +Any Any -> S-tag +C-tag+Any C-tag -> S-tag +C-tag C-tag -> S-tag +C'-tag+C-tag C-tag -> S-tag (C-tag = S-tag) C-tag -> S-tag C-tag -> S-tag +C'-tag pri-tag -> S-tag +pri-tag
Issue 01 (2011-10-30)
185
Traffic Classification Type
Traffic Classification Parameter
Default Transforming Mode
Configurable Transforming Mode AddDouble Translate TranslateAndA dd
Tag Processing Policies pri-tag -> S-tag +C-tag+pri-tag pri-tag -> S-tag pri-tag -> S-tag +C'-tag untag -> S-tag untag -> S-tag +C-tag Any -> S-Tag +Any Any -> S-tag +C-tag+Any C-VLAN range -> S-tag+CVLAN range C-tag -> S-tag +C-tag C-tag -> S-tag +C'-tag+C-tag C-tag -> S-tag (C-tag = S-tag) C-tag -> S-tag C-tag -> S-tag +C'-tag pri-tag -> S-tag +pri-tag pri-tag -> S-tag +C-tag+pri-tag pri-tag -> S-tag pri-tag -> S-tag +C'-tag C-tag -> S-tag +C-tag C-Tag -> S-tag +C'-tag+C-tag
untagged
Add
Add AddDouble
other-all (any other)
Add
Add AddDouble
VLAN range
Add
Add
By VLAN VLAN: 1-4095 +802.1p priority P-bits: 0-7
Add
Add AddDouble Transparent Translate TranslateAndA dd
VLAN: priority-tagged P-bits: 0-7
Add
Add AddDouble Translate TranslateAndA dd
By VLAN +EtherType
VLAN: 1-4095 EtherType: PPPoE/IPoE
Add
Add AddDouble
Issue 01 (2011-10-30)
186
Traffic Classification Parameter
Default Transforming Mode
Configurable Transforming Mode Transparent Translate TranslateAndA dd
Tag Processing Policies C-tag -> S-tag (C-tag = S-tag) C-tag -> S-tag C-tag -> S-tag +C'-tag pri-tag -> S-tag +pri-tag pri-tag -> S-tag +C-tag+pri-tag pri-tag -> S-tag pri-tag -> S-tag +C'-tag untag -> S-tag untag -> S-tag +C-tag S-tag+C-tag -> S'-tag+C'-tag S-tag+C-tag -> S'-tag
VLAN: priority-tagged EtherType: PPPoE/IPoE
Add
Add AddDouble Translate TranslateAndA dd
VLAN: untagged EtherType: PPPoE/IPoE By dual-VLAN Outer VLAN: 1-4095 Inner VLAN: 1-4095
Add
Add AddDouble
TranslateAndR emove
TranslateDoubl e TranslateAndR emove
Assuming the SVLAN attribute is common, Table 9-14 lists the default and configurable VLAN tag transforming modes of switch-oriented traffic streams and the tag processing policies for upstream packets. Table 9-14 VLAN tag transforming mode (2) Traffic Classification Type Single service Traffic Classificati on Parameter None (Any) Default Transforming Mode Add Configurable Transforming Mode Add Tag Processing Policies
untag -> S-tag pri-tag -> S-tag
By EtherType
PPPoE
Add
Add
IPoE
Add
Add
Issue 01 (2011-10-30)
187
Traffic Classification Type By VLAN
Traffic Classificati on Parameter C-VLAN: 1-4095
Default Transforming Mode Transparent
Configurable Transforming Mode Transparent
Tag Processing Policies
C-tag -> S-tag (C-tag = S-tag, GEM port subtending) C-tag -> S-tag pri-tag -> S-tag untag -> S-tag N/A N/A C-tag -> S-tag (C-tag = S-tag, GEM port subtending) C-tag -> S-tag pri-tag -> S-tag
Translate prioritytagged untagged other-all (any other) VLAN range By VLAN +802.1p priority VLAN: 1-4095 P-bits: 0-7 Translate VLAN: prioritytagged P-bits: 0-7 By VLAN +EtherType VLAN: 1-4095 EtherType: PPPoE/IPoE Transparent Translate Translate Add N/A N/A Transparent
Translate Translate Add N/A N/A Transparent
Translate Translate
Transparent
C-tag -> S-tag (C-tag = S-tag, GEM port subtending) C-tag -> S-tag pri-tag -> S-tag
Translate VLAN: prioritytagged EtherType: PPPoE/IPoE VLAN: untagged EtherType: PPPoE/IPoE Add Translate
Translate Translate
Add
untag -> S-tag
Issue 01 (2011-10-30)
188
Traffic Classification Type By dual-VLAN
Traffic Classificati on Parameter Outer VLAN: 1-4095 Inner VLAN: 1-4095
Default Transforming Mode TranslateAndRemove
Configurable Transforming Mode TranslateAndRemove
S-tag+C-tag -> S'-tag
Assuming the SVLAN attribute is stacking, Table 9-15 lists the default and configurable VLAN tag transforming modes of switch-oriented traffic streams and the tag processing policies for upstream packets. Table 9-15 VLAN tag transforming mode (3) Traffic Classification Type Single service Traffic Classificati on Parameter None (Any) Default Transforming Mode AddDouble Configurable Transforming Mode AddDouble Tag Processing Policies
untag -> S-tag +C-tag pri-tag -> S-tag +C-tag C-tag -> S-tag C'tag+C-tag
By EtherType
PPPoE
AddDouble
AddDouble
untag -> S-tag +C-tag pri-tag -> S-tag +C-tag C-tag -> S-tag +C'-tag+C-tag
IPoE
AddDouble
AddDouble
untag -> S-tag +C-tag pri-tag -> S-tag +C-tag C-tag -> S-tag +C'-tag+C-tag
By VLAN
C-VLAN: 1-4095
Transparent
Transparent
C-tag -> S-tag (C-tag = S-tag, GEM port subtending)
Issue 01 (2011-10-30)
189
Traffic Classificati on Parameter
Default Transforming Mode TranslateAndAd d
Configurable Transforming Mode TranslateAndAd d TranslateAndAd d AddDouble N/A Add
C-tag -> S-tag +C'-tag pri-tag -> S-tag +C'-tag untag -> S-tag +C-tag N/A C-VLAN range > S-tag+CVLAN range C-tag -> S-tag (C-tag = S-tag, GEM port subtending) C-tag -> S-tag C'tag pri-tag -> S-tag +C'-tag
prioritytagged untagged other-all (any other) VLAN range
TranslateAndAd d AddDouble N/A Add
By VLAN VLAN: +802.1p priority 1-4095 P-bits: 0-7
Transparent
Transparent
TranslateAndAd d VLAN: prioritytagged P-bits: 0-7 By VLAN +EtherType VLAN: 1-4095 EtherType: PPPoE/IPoE Transparent TranslateAndAd d
TranslateAndAd d TranslateAndAd d
Transparent
C-tag -> S-tag (C-tag = S-tag, GEM port subtending) C-tag -> S-tag +C'-tag pri-tag -> S-tag +C'-tag
TranslateAndAd d VLAN: prioritytagged EtherType: PPPoE/IPoE VLAN: untagged EtherType: PPPoE/IPoE AddDouble TranslateAndAd d
TranslateAndAd d TranslateAndAd d
AddDouble
untag -> S-tag +C-tag
Issue 01 (2011-10-30)
190
Traffic Classification Type By dual-VLAN
Traffic Classificati on Parameter Outer VLAN: 1-4095 Inner VLAN: 1-4095
Default Transforming Mode TranslateDouble
Configurable Transforming Mode TranslateDouble
S-tag+C-tag -> S'-tag+C'-tag
VLAN Tag Transforming and Packet Forwarding

During VLAN tag transforming of traffic streams, the SVLAN and the CVLAN must be specific. Generally, SVLAN is a service VLAN or a network-side VLAN, and CVLAN is a customerside VLAN. Before a switch-oriented traffic stream is created, the SVLAN to be bound to the traffic stream must be created, and the attribute (common, QinQ or stacking) and forwarding mode (VLAN +MAC or SVLAN+CVLAN) of the SVLAN must also be configured. The type of the SVLAN specified during the creation of a traffic stream must be smart or MUX. l For services of residential users: If the N:1 service is configured (traffic streams of multiple users are aggregated to the same SVLAN), the SVLAN must be a smart VLAN, with the common attribute and the VLAN+MAC forwarding mode. If the 1:1 service is configured and each traffic stream of each user uses two VLAN tags (SVLAN+CVLAN), the VLANs must be smart VLANs, with the stacking attribute and the SVLAN+CVLAN forwarding mode (recommended, or the default VLAN+MAC mode). If the 1:1 service is configured and each traffic stream of each user uses a single SVLAN, the VLAN must be a MUX VLAN, with the common attribute and the SVLAN +CVLAN forwarding mode (recommended, or the default VLAN+MAC mode). l For Layer 2 services of commercial users: If traffic streams of each commercial user use a single SVLAN with transparent transmission, the VLAN must be a MUX VLAN, with the QinQ attribute and the VLAN +MAC forwarding mode (or SVLAN+CVLAN). If traffic streams of multiple commercial users use the same SVLAN with transparent transmission, the VLAN must be a smart VLAN, with the QinQ attribute and the VLAN +MAC forwarding mode (or SVLAN+CVLAN).
Example:VLAN Tag Transforming

There is an example to illustrate VLAN Tag Transforming.
Issue 01 (2011-10-30)
191
Figure 9-10 Example of VLAN Tag Transforming

Access Node HSI CPE
VOD
STB
VoIP Traffic Classification translate and Add by VLAN + EtherType HSI VOD VoIP PPPoE IPoE PPPoE CVLAN=101 CVLAN=201 CVLAN=301 PPPoE IPoE PPPoE SVLAN=5 SVLAN=6 SVLAN=7 CVLAN=101 CVLAN=201 CVLAN=301
In Figure 9-10: l l l l Traffic Classification Type: By VLAN+EtherType. Traffic Classification Parameter:VLAN 101+PPPoE, VLAN 201+IPoE and VLAN 301 +PPPoE. Transforming Mode: translate and Add. Tag Processing Policies: 101(C-Tag) -> 5(S-Tag)+101(C'-Tag), 102(C-Tag) -> 6(S-Tag) +102(C'-Tag), 03(C-Tag) -> 7(S-Tag)+103(C'-Tag).
9.7 Forwarding Policy

This topic provides the definition, specifications, availability, and principle of the forwarding policy feature.
9.7.1 Introduction
Definition
On a Layer 2 device, a packet is generally forwarded based on the VLAN and MAC address information contained in the packet. That is, forwarding is based on the VLAN+MAC. The MA5600T/MA5603T supports forwarding packets based on the VLAN, that is, based on the SVLAN+CVLAN.
Purpose
Forwarding based on the SVLAN+CVLAN solves the problem that the Layer 2 forwarding of the MA5600T/MA5603T depends on the MAC address learning, and has the following advantages: 1. 2. Saving MAC addresses Preventing occurrence of unknown unicast packets caused by aging of dynamic MAC addresses. Broadcasting unknown unicast packets threatens the security of the device.
Issue 01 (2011-10-30)
3.
Ensuring security by solving problems such as MAC spoofing and attack.
The MA5600T/MA5603T supports the following specifications of the forwarding policy feature: l l l l l l Forwarding based on the outer VLAN+MAC Forwarding based on the SVLAN+CVLAN Forwarding based on the VLAN+COS Forwarding based on the VLAN+MAC+COS Forwarding based on port+SVLAN+CVLAN on the SPUA board Forwarding or dropping broadcast packets, unknown unicast packets, and unknown multicast packets based on the VLAN
9.7.3 Availability
License Support
Version Support
Table 9-16 Version support Product MA5600T/ MA5603T Version V800R007C00 and later
Hardware Support
All service boards support forwarding based on the SVLAN+CVLAN. For control boards, only the SCUN control board supports forwarding based on the SVLAN+CVLAN.
Miscellaneous
The possible impacts caused by the forwarding based on the SVLAN+CVLAN: l l l l l The VLAN must be the smart VLAN or MUX VLAN, and cannot be the standard VLAN. A MUX VLAN of any attribute (common, stacking and QinQ) supports forwarding based on the SVLAN+CVLAN. A smart VLAN of the common attribute does not support forwarding based on the SVLAN +CVLAN. In this case, the forwarding based on the VLAN+MAC is used. A smart VLAN of the stacking or QinQ attribute supports forwarding based on the SVLAN +CVLAN. The system does not support the broadcast suppression function only if the packets of a VLAN are forwarded based on the SVLAN+CVLAN.
Issue 01 (2011-10-30)
l l
The system does not support the VMAC function only if the packets of a VLAN are forwarded based on the SVLAN+CVLAN. The traffic that is forwarded based on the SVLAN+CVLAN does not support the anti MAC spoofing function. The traffic that is forwarded based on the VLAN+MAC, however, supports this function. The traffic that is forwarded based on the SVLAN+CVLAN does not support the static MAC address function. The traffic that is forwarded based on the VLAN+MAC, however, supports this function. The SVLAN+CVLAN forwarding feature can be enabled for a VLAN. After this feature is enabled, the packet suppression function is disabled. The packet suppression function cannot be enabled even if there is traffic forwarded based on the VLAN+MAC in the system.
9.7.4 Principle
VLAN+MAC Forwarding
In general, the LAN switch forwards packets based on the VLAN+MAC. With the VLAN+MAC forwarding policy, the LAN switch automatically learns about the mapping among the VLAN, source MAC address, and incoming port when packets enter the LAN switch, and according to the VLAN and destination MAC address, searches for the corresponding outgoing port and transmits the packets through this port. In the VLAN+MAC forwarding mechanism, in the case of a broadcast MAC address or unicast MAC address, packets are broadcast in the VLAN. That is, packets are duplicated and transmitted to every port in the VLAN.
SVLAN+CVLAN Forwarding
The two-layer VLANs (SVLAN+CVLAN) is an extension of the VLAN. This expands the VLAN identification range. In addition, S and C generally have special meanings, for example, S identifies the service and C identifies the customer. Thus, each "SVLAN+CVLAN" uniquely identifies one type of service of one customer, and SVLAN+CVLAN forwarding can be implemented. SVLAN+CVLAN forwarding refers to the feature with which a unique outgoing port (or service virtual port) can be searched for according to the Layer 2 mapping relation composed of twolayer VLAN IDs (SVLAN+CVLAN IDs) to implement forwarding for the packets of a VLAN.
NOTE
Only one service virtual port can be established in a MUX VLAN. Therefore, a MUX VLAN with the common attribute can also support VLAN-based forwarding. A smart VLAN supports VLAN-based forwarding only when its attribute is QinQ or stacking.
The SVLAN+CVLAN forwarding entry needs not be learned dynamically. The system automatically creates the forwarding entry during establishment of the service virtual port. According to the forwarding entry, upstream packets are transmitted through the corresponding upstream port and downstream packets are transmitted through the corresponding service virtual port.
VLAN+MAC+CoS Forwarding
When the ONT or CPE accesses the MA5600T/MA5603T in the Layer 3 mode, one VLAN may be used to identify users and the 802.1p priority may be used to identify services in the upstream
direction, and after the MAC NAT function is enabled on the ONT or CPE, the MAC addresses carried in multiple types of services may be the same. To solve this problem, the MA5600T/ MA5603T needs to support the VLAN+MAC+CoS forwarding. The VLAN+MAC+CoS forwarding (service flow bundle) can be divided into two steps: Determine the unique user according to the VLAN+MAC. Find out the corresponding service flow according to the 802.1p priority. The MA5600T/MA5603T implements service flow bundle as follows: The MA5600T/ MA5603T sets up a service flow for each service of a user and transmits all services to the same SVLAN in the upstream direction. This SVLAN may be an N:1 VLAN, that is, the user may be in the same upstream VLAN as other users. In this case, set the VLAN+MAC forwarding mode for the SVLAN.
VLAN+CoS Forwarding and SVLAN+CVLAN+CoS Forwarding

When the ONT or CPE accesses the MA5600T/MA5603T in the Layer 3 mode, one VLAN may be used to identify users and 802.1p priority may be used to identify services in the upstream direction. In this case, the MA5600T/MA5603T needs to support the VLAN+CoS forwarding or SVLAN+CVLAN+CoS forwarding. The service flow bundle forwarding is the VLAN+CoS forwarding or SVLAN+CVLAN+CoS forwarding. The VLAN+CoS forwarding or SVLAN+CVLAN+CoS forwarding (service flow bundle) can be divided into two steps: Determine the unique user according to the VLAN or the SVLAN+CVLAN. Find out the corresponding service flow according to the 802.1p priority. The MA5600T/MA5603T implements service flow bundle as follows: Set up a service flow for each service of a user and transmit all services to the same SVLAN or SVLAN+CVLAN in the upstream direction. This SVLAN or SVLAN+CVLAN uniquely identifies the user. In this case, set the SVLAN+CVLAN forwarding mode for the SVLAN.
9.8 Bridging
With the bridging feature enabled on the MA5600T/MA5603T, the access users on the MA5600T/MA5603T can communicate with each other at Layer 2.
9.8.1 Introduction
Definition
Access user bridging is a feature with which the access users on one MA5600T/MA5603T can communicate with each other at Layer 2. User bridging can be VLAN-based or global user bridging, each of which can be subdivided into intra-board and inter-board user bridging.
Purpose
When an access device (such as an MA5600T/MA5603T) provisions common access services, all access users are isolated from each other at Layer 2 for sake of security. This causes the following two conditions: l In the case of the QinQ service, Layer 2 forwarding is required; however, ports are isolated from each other at Layer 2 on one MA5600T/MA5603T and thus Layer 2 forwarding cannot
Issue 01 (2011-10-30)
be implemented. Therefore, the QinQ service can only be implemented between different MA5600T/MA5603Ts. l In the case of the common access service, the IP addresses of two users on one MA5600T/ MA5603T are generally in the same network segment. These two users, however, cannot interoperate with each other in this network segment due to Layer 2 isolation. In this case, the upper-layer gateway is required to support Layer 3 forwarding and the ARP proxy. That is, the upper-layer gateway is exposed to more requirements.
All the preceding service application problems are originated from the failure in bridging among all access users on one MA5600T/MA5603T. The purpose of this feature is just to implement bridging among the access users on one MA5600T/MA5603T.
The SPUA/GPBD board works with the SCUN control board to implement bridging among the access users of the SPUA or GPBD board, or among the access users of the SPUA and GPBD boards. l l The GPBD board provides 8 GPON ports on the front panel, and each port supports a 1:128 split ratio. The SPUA board provides 8 GE ports and 2 10GE ports on the front panel. It can function as an upstream board or service access board. It supports the access user bridging feature only when it functions as a service access board. The SCUN control board, core of system control and service switching, provides 4 GE ports on the front panel.
With the SCUN control board configured, Supports VLAN-based bridging between AIUG boards, and does not support bridging between users of different ports or the same port of the AIUG board. l l l When the SCUN control board is configured, VLAN-based intra-board and inter-board user bridging for GPBC, GPBD, SPUA, and OPGD boards are supported. When the SCUN control board is configured, VLAN-based inter-AIUG-board user bridging is supported. When the SCUL control board is configured, global inter-board and intra-board user bridging for the GPBC, GPBD boards are supported.

The following is the reference document of this feature: l DSL Forum TR-101: Migration to Ethernet-Based DSL Aggregation
9.8.4 Availability
License Support
The access user bridging feature is an optional feature of the MA5600T/MA5603T, and the corresponding service is controlled by the license.
Issue 01 (2011-10-30)
196
Version Support
Table 9-17 Version support User Bridging When the SCUN control board is configured, VLAN-based intra-board and inter-board user bridging for GPBC, GPBD, SPUA, and OPGD boards are supported. When the SCUN control board is configured, VLAN-based inter-AIUG-board user bridging is supported. When the SCUL control board is configured, global inter-board and intra-board user bridging for the GPBC and GPBD boards are supported. Version
V800R007C00 and later versions
V800R007C00 and later versions
V800R008C05 V800R010
Feature Dependency
l When the SCUN control board is configured VLAN-based user bridging conflicts with S+C forwarding. VLAN-based user bridging conflicts with ARP proxy. l When the SCUL control board is configured Global user bridging conflicts with S+C forwarding. Global user bridging conflicts with ARP proxy. l l The VLAN range traffic streams do not support user bridging. After global user bridging is enabled, an S+C traffic stream can receive the broadcast packets sent by itself.
9.8.5 Principle
Architecture Model of the Access User Bridging Feature
The following section describes the architecture model of the access user bridging feature. User bridging can be VLAN-based or global user bridging.
Issue 01 (2011-10-30)
197
Figure 9-11 Architecture model of VLAN-based user bridging

Upper-layer network
board 1 PON port PON port One VLAN Inter-board user bridging GE port
board 2 GE port
SPL ONU User1 ONU User2
SPL ONU User3
One IP network segment
User4
User4
One VLAN Intra-board user briding
One VLAN Intra-board user briding
As shown in Figure 9-11, the following bridging functions are implemented on the MA5600T/ MA5603T after the access user bridging feature is enabled for a VLAN. l l Inter-board user bridging: bridging among ports on different boards, such as users 1, 2, 3 and users 4, 5 Intra-board user briding: Bridging among different ONUs that are connected to one PON port, such as user 1 and user 2 Bridging among different ONUs that are connected to different PON ports on one PON board, such as user 1, user 2, and user 3 Bridging among different ports on one board, such as user 4 and user 5
Issue 01 (2011-10-30)
198
Figure 9-12 Architecture model of global user bridging

Upper-layer network
board1 PON port
Different VLAN board 2 (global) PON port PON port Inter-board user PON port bridging SPL ONU VLAN C SPL ONU
VLAN A SPL ONU User1 ONU User2 SPL VLAN B ONU User3
One IP network segment
User4
User5
Different VLAN (global) Intra-board user briding
As shown in Figure 9-12, the following bridging functions are implemented on the MA5600T/ MA5603T after the access user bridging feature is enabled globally. l l Inter-board user bridging: bridging among ports in different VLANs on different boards, such as users 1, 2, 3 and users 4, 5 Intra-board user bridging: bridging among different ONUs in different VLAANs that are connected to different PON ports on one PON board, such as user 1, user 2, and user 3
NOTE
For details about the support for VLAN-based and global user bridging on each board, see 9.8.2 Specifications.
Issue 01 (2011-10-30)
199
Network Applications
Figure 9-13 Network applications of the access user bridging feature
PC
ONU SPL ONU
MA5600T/ MA5603T
VLAN PC ONU PC ONU PC
IP
VPN
As shown in Figure 9-13, on one MA5600T/MA5603T, both bridging of the enterprise private line users (the red line) and bridging of common access users (the yellow line) are implemented. These applications are differentiated by using the VLAN. A QinQ VLAN can be used for the enterprise private line service. Enable the bridging function for this VLAN to implement bridging among the private line users on an MA5600T/MA5603T. If bridging among the users in a public network VLAN is also required, enable the bridging function for this VLAN directly.

Glossary
Table 9-18 Glossary of the terms related to the access user bridging feature Term User board S+C forwarding Description In this document, a user board refers to the board that provides users with the access service. In the S+C forwarding mode, Ethernet packets are forwarded according to the two-layer VLAN tags in the header. The external-layer VLAN tag is the S-tag and the internal-layer tag is the C-tag.
Issue 01 (2011-10-30)
200

Table 9-19 Acronyms and abbreviations of the access user bridging feature Acronym/ Abbreviation SCUN Full Spelling Description The SCUN control board. It provides up to 24 10GE ports, and 4 GE ports on the front panel. It provides 8 GE ports and 2 10GE ports on the front panel. Null Null Null Null Null Null Null
Super Control Unit Board VerN
SPU OLT ONU ONT VMAC ARL LTM LTR
Service Process Unit Optical Line Terminal Optical Network Unit Optical Network Terminal Virtual MAC Address Resolution List Linktrace Message Linktrace Reply
Issue 01 (2011-10-30)
201
10 QoS
10
About This Chapter
10.1 QoS Processing
QoS
Quality of service (QoS) provides end-to-end service quality assurance for users by setting a series of QoS parameters, such as service availability, delay, jitter, and packet loss ratio. It includes technologies such as priority processing, traffic policing, ACL policy, and congestion avoidance and management.
10.2 Traffic Classification This topic covers the overview, specifications, availability, and principle of the traffic classification policy. 10.3 Priority Processing This topic covers the overview, availability, impact, and principle of priority processing. 10.4 Traffic Policing This topic covers the overview, availability, impact, and principle of traffic policing. 10.5 ACL Policy Using the preset access control list (ACL) policy, the system permits or refuses data packets to pass. 10.6 Congestion Avoidance and Management This topic covers the overview, specifications, availability, and principle of congestion avoidance and management. 10.7 HQoS In the conventional quality of service (QoS), traffic scheduling is based on the port. The hierarchical QoS (HQoS) is a QoS technology that controls user traffic on a port with finer granularity and also schedules services of a user based on the service priority. 10.8 QoS Network Application 10.9 Glossary, Acronyms, and Abbreviations This topic provides glossary, acronyms, and abbreviations relevant to the QoS feature.
Issue 01 (2011-10-30)
202
10 QoS
10.1 QoS Processing

The QoS feature refers to the end-to-end quality assurance for users, including priority processing, traffic policing, ACL policy, congestion avoidance and management. The following briefly describes QoS processing on the MA5600T/MA5603T. For details about each QoS action, see the relevant topics.
Upstream QoS Processing

Figure 10-1 illustrates the upstream QoS processing on the MA5600T/MA5603T. Figure 10-1 Upstream QoS processing on the MA5600T/MA5603T
Congestion management 7 6 5 4 3 2 1 0 Congestion management 7 6 5 4 3 2 1 0
Traffic classification
Traffic policy
Congestion avoidance
Priority processing
ACL policy
Traffic streams
Service board
Control board
The MA5600T/MA5603T implements QoS processing of upstream traffic streams as follows: 1. After entering the service board from the user port, user packets are performed with QoS processing as follows: (1) Traffic classification: User services are differentiated according to the characteristics of user Ethernet packets and different services achieve different QoS guarantees. (2) Priority processing: Different priority processing policies are set for different traffic streams so that these traffic streams are scheduled according to their priorities when congestion occurs on the local device or upper-layer network. (3) Traffic policing: It is used to limit the traffic volume and address the burst of a certain incoming connection on a network. When the packets meet certain conditions, for example, when the traffic of a connection is too heavy, traffic policing takes different actions, such as dropping the packets, or coloring the packets (re-setting the priority of the packets). In this way, the port can maintain a stable rate, which avoids impact on the upper-layer devices. Generally, CAR is used to limit the traffic of a certain type of packets. (4) Congestion avoidance: When congestion occurs, unqualified packets are dropped in advance using an early drop algorithm (RED or WRED) to avoid further congestion. (5) Congestion management: Outgoing packets with different priorities enter different priority queues through PQ or WRR scheduling so as to manage traffic on the device. 2.
Issue 01 (2011-10-30)
After entering the control board, packets are performed with QoS processing as follows:
10 QoS
(1) ACL policy: A series of match rules are configured to identify and filter data packets that match the rules. After the specific objects are identified, the system permits or refuses the corresponding data packets to pass according to the preset rules. ACLbased traffic filtering is a prerequisite for QoS. ACL together with QoS improves the system security. (2) Congestion avoidance: When congestion occurs on a port, the early drop algorithm is used to avoid further congestion. (3) Congestion management: Outgoing packets with different priorities enter different priority queues through queue scheduling.
Downstream QoS Processing

Figure 10-2 illustrates the downstream QoS processing on the MA5600T/MA5603T. The downstream QoS processing is reverse to the upstream QoS processing. Figure 10-2 Downstream QoS processing on the MA5600T/MA5603T
Congestion management 7 6 5 4 3 2 1 0 Congestion management 7 6 5 4 3 2 1 0
Traffic classification
10.2 Traffic Classification

This topic covers the overview, specifications, availability, and principle of the traffic classification policy.
Priority processing
Service board
Traffic streams
Traffic policy
Control board
ACL policy
10.2.1 Overview
Definition
Traffic classification is a technology that differentiates services by packets classification according to the characteristics of user Ethernet packets and certain rules, so as to implement different processing operations and provide different services.
Purpose
The purpose of traffic classification is to differentiate traffic streams to provide different QoS guarantees for various services of users. The system implements traffic-stream-based service mapping and makes preparations for the subsequent QoS actions, for example, transforming between user VLANs and network VLANs, upstream and downstream CAR, priority marking, and queue scheduling.
10 QoS
Traffic streams can be classified by (for details, see Table 10-1): l l l l l l Physical port/logical port. In this mode, the "Any" rule is adopted, and traffic on the entire port is classified as one traffic stream. Hence, a single port carries a single service. EtherType. In this mode, traffic classification differentiates between the IPoE and PPPoE encapsulation types. CVLAN. CVLAN+802.1p priority. CVLAN+EtherType. Dual-VLAN tags (SVLAN+CVLAN).
Table 10-1 Specifications of traffic classification Traffic Classification Type Single service By EtherType Traffic Classification Parameter None (Any) PPPoE IPoE Description
No traffic classification is performed. The EtherType is 0x8863 or 0x8864. All Ethernet packets that do not match the PPPoE encapsulation type are regarded as IPoE packets. VLANs 1-4095 are normal VLAN tags. Priority-tagged is a tag of VLAN 0, and is also called null-tag. Untagged packets match this rule. Packets that do not match the other rules match this rule.
By CVLAN
1-4095 priority-tagged untagged other-all (any other)
Issue 01 (2011-10-30)
205
10 QoS
Traffic Classification Parameter VLAN range
Description
The ranges of start VLAN ID and end VLAN ID are both 1 to 4095, but the end VLAN ID must be larger than the start VLAN ID. Currently, only EPON supports VLAN range, which corresponds to the EPON port, not LLID. The VLAN range (also called raw streams) in EPON is actually a type of bulkprocessed traffic streams based on SVLAN +CVLAN forwarding. It is particularly applicable to the wholesale scenarios, for example, bulk operation on the same type of services (same SVLAN) of all ONUs (different CVLANs) connected to a PON port. In this scenario, when a user is added, no additional traffic stream is required when the CVLAN of this user is within the VLAN range.
By CVLAN +802.1p priority (P-bits)
VLAN: 1-4095 P-bits: 0-7 VLAN: priority-tagged P-bits: 0-7
VLANs 1-4095 are normal VLAN tags.
Priority-tagged is a tag of VLAN 0. In this case, only the value of p-bits is required to be input. VLANs 1-4095 are normal VLAN tags.
By CVLAN +EtherType
VLAN: 1-4095 EtherType: PPPoE, IPoE VLAN: priority-tagged EtherType: PPPoE, IPoE VLAN: untagged EtherType: PPPoE, IPoE
Priority-tagged is a tag of VLAN 0.
Untagged PPPoE or IPoE packets adopt this rule. It is traffic classification by dual-VLAN tags.
By dual-VLAN (SVLAN +CVLAN)
Outer VLAN: 1-4095 Inner VLAN: 1-4095
Supports setting of traffic streams description. The SCUB/SCUF control board supports description settings for 8K traffic streams. The SCUN/SCUL control board supports description settings for 24K traffic streams.
Issue 01 (2011-10-30)
206
10 QoS
10.2.3 Availability
License Support
The traffic classification feature does not require a license.
Version Support
Table 10-2 Version support Product MA5600T/MA5603T Version V800R007C00 and later versions
10.2.4 Principle
Traffic classification on the MA5600T/MA5603T is a technology that differentiates user services according to the characteristics of user Ethernet packets. The major purpose of traffic classification is to support multi-service applications and guarantee QoS for each service (each traffic stream) of each user. After packets enter the MA5600T/MA5603T, the MA5600T/MA5603T performs traffic classification and then provides different QoS services for different traffic streams. Figure 10-3 shows the traffic classification process. Figure 10-3 Traffic classification process
Different QoS services for different traffic streams Best service Golden service Silver service Bronze service
Packets
Traffic classifcation
Generally, one physical port or logical port can have only one traffic classification rule. The Ethernet port on the SPUA board supports traffic classification by single-VLAN and dualVLAN. However, the single VLAN ID must be different from the outer VLAN ID of the dualVLAN. Figure 10-4 illustrates how to classify traffic streams based on the VLAN so that the classified traffic streams are processed with different QoS services.
Issue 01 (2011-10-30)
207
10 QoS
Figure 10-4 VLAN-based traffic classification

Classified by VLAN
Internet: VLAN 100 802.1P marking IPTV: VLAN 200 802.1P marking Service VoIP: VLAN 300 port 802.1P marking
trTCM &CAR trTCM &CAR trTCM &CAR
DEI marking DEI marking DEI marking Service board

PQ+ WRR
Upstream port
10.3 Priority Processing

This topic covers the overview, availability, impact, and principle of priority processing.
10.3.1 Overview
Definition
Priority processing of the MA5600T/MA5603T mainly includes remarking the VLAN priority, trusting the user-side CoS priority, and trusting the user-side ToS priority for packets.
Purpose
According to different priority processing policies, the inner and outer VLAN priorities are configured or the user-side priority is trusted for traffic streams. In this way, packets are scheduled according to their priorities when congestion occurs on the local device or upper-layer network.
Priority Re-marking
l Outer VLAN priority: Copies the outer VLAN priority of the user packet as the outer VLAN priority of the traffic stream. Copies the inner VLAN priority of the user packet as the outer VLAN priority of the traffic stream. Copies the ToS priority of the user packet as the outer VLAN priority of the traffic stream in the upstream direction. Specifies the outer VLAN priority of the traffic stream.
10 QoS
Inner VLAN priority: Copies or maps the outer VLAN priority of the user packet as the inner VLAN priority of the traffic stream. Only the SPUA board supports priority mapping. Copies or maps the inner VLAN priority of the user packet as the inner VLAN priority of the traffic stream. Only the SPUA board supports priority mapping. Copies the ToS priority of the user packet as the inner VLAN priority of the traffic stream in the upstream direction. Specifies the inner VLAN priority of the traffic stream.
Priority-based Queuing Policy

l l l Local priority Egress outer VLAN priority Ingress outer VLAN priority The SPUA/OPGD board does not support queuing based the egress outer VLAN priority. Connection-oriented traffic streams do not support queuing based on the ingress outer VLAN priority. The GPBC board supports queuing based on the ingress outer VLAN priority only when the re-marking policy of the egress outer VLAN priority is copying the ingress outer VLAN.
Others
The system supports setting of the DSCP priority for the protocol packets sent by the VLAN interface. The DSCP priority for DHCP packets and that for routing protocol packets (including OSPF, IS-IS, RIP, BGP, and PIM-SSM packets) can be set separately.
10.3.3 Availability
Relevant NEs
The priority processing feature involves only the MA5600T/MA5603T.
License Support
The priority processing feature does not require a license.
Version Support
Issue 01 (2011-10-30)
209
10 QoS
10.3.4 Principle
Priority processing allows the 802.1p priority to be remarked according to certain rules. Priority processing is a prerequisite for queue scheduling. For queue scheduling on the MA5600T/ MA5603T, packets enter queues according to their outer VLAN priorities. At the same time, priority processing also makes preparations for the scheduling on the upper-layer network.
802.1p Priority and IP Precedence

The priority of a packet can be 802.1p priority or IP precedence. 1. 802.1p priority 802.1p priority refers to the packet priority specified at the link layer, which is the class of service (CoS). The 802.1p priority occupies three bits in the VLAN tag (the following figure shows the position of the 802.1p priority in an Ethernet frame), as defined in IEEE802.1Q. The priority field represents the 802.1p priority, which indicates the priority of an Ethernet frame. This field comprises three bits and its value ranges from 0 to 7. In detail, 0 stands for the lowest priority level and 7 the highest priority level. By using the eight priority levels, this field specifies which packet to transmit first in the case of congestion on a port. 802.1p priority is also called the CoS priority. Figure 10-5 802.1q frame format
802.1Q header Destination address Source address TPID TCI Length /Type Data FCS (CRC-32)
6 bytes
6 bytes
4 bytes
2 bytes
46-1517 bytes
4 bytes
TPID (Tag Protocol Identifier) 0x8100 16 bits
TCI (Tag Control Information) Priority 3 bits CFI 1 bits VLAN ID 12 bits
2.
IP precedence As defined in the IP protocol, differentiated services code point (DSCP) and type of service (ToS) occupy the same field (one byte) in the IP header. The IP bearer network device identifies whether to fill DSCP or ToS in the field and, according to the setting, schedules and forwards packets to ensure QoS for different services. ToS in the IP header specifies traffic classification. It is used to specify traffic classification rather than the priority (the priority is determined by the device). The ToS field comprises
Issue 01 (2011-10-30)
210
10 QoS
eight bits, including a 3-bit priority sub-field (now ignored), 4-bit ToS sub-field, and one reserved bit (set to 0). The four bits in the ToS sub-field represent the minimum delay, maximum throughput, maximum reliability, and minimum cost respectively. Only one of the four bits can be set. If all four bits are set to 0, it indicates the common service. DSCP is defined based on the IPv4 ToS. As shown in Figure 10-6, the least significant six bits in the DS field (bits 0-5) are used to differentiate DSCPs and the most significant two bits (bits 6 and 7) are reserved. The least significant three bits in the DS field (bits 0-2) are the class selector code point (CSCP), which is a type of DSCP. Figure 10-6 IP precedence
DS Field 0 1 2 3 4 5 6 7 unused 0 1 2 IPv4 TOS 3 4 5 6 7 0
DSCP
CSCP
Precedence
ToS
DSCP is used to select the corresponding per-hop behavior (PHB) on each node of the network. PHB describes the external visible behaviors when the DS node is used for data stream aggregation. IETF has defined three types of PHB: expedited forwarding (EF), assured forwarding (AF), and best-effort. For example, BE: DSCP=000000 EF: DSCP=101110 The AF code points are as follows: Low Discard Priority, j=1 AF (i=4) AF (i=3) AF (i=2) AF (i=1) 100010 011010 010010 001010 Medium Discard Priority, j=2 100100 011100 010100 001100 High Discard Priority, j=3 100110 011110 010110 001110
In different levels of discard priorities, the first three bits in each type of AF, however, are the same, for example, the first three bits in AF1 are 001, 010 in AF2, 011 in AF3, and 100 in AF4. Bits 3 and 4 indicate the discard priority, with values 01, 10, and 11. The larger the value, the higher the discard priority.
SVLAN Priority Processing

The MA5600T/MA5603T processes the outer VLAN (SVLAN) priority as follows:

NOTE
10 QoS
The user VLAN priority indicates the VLAN priority of the packet transmitted to the device from the user side or network side.
l l l l
Trusting the user CoS: Copies the outer VLAN priority of the user packet as the outer VLAN priority of the traffic stream. Trusting the user inner CoS: Copies the inner VLAN priority of the user packet as the outer VLAN priority of the traffic stream. Trusting the user ToS: Copies the ToS priority of the user packet as the outer VLAN priority of the traffic stream in the upstream direction. Trusting the local priority: Specifies the outer VLAN priority of the traffic stream.
Upstream packets support these four priority processing modes. Downstream packets, however, support only three processing modes and do not support "trusting the user ToS".
CVLAN Priority Processing

l l Trusting the user CoS: Copies or maps the outer VLAN priority of the user packet as the inner VLAN priority of the traffic stream. Only the SPUA board supports priority mapping. Trusting the user inner CoS: Copies or maps the inner VLAN priority of the user packet as the inner VLAN priority of the traffic stream. Only the SPUA board supports priority mapping. Trusting the user ToS: Copies the ToS priority of the user packet as the inner VLAN priority of the traffic stream in the upstream direction. Trusting the local priority: Specifies the inner VLAN priority of the traffic stream.
l l
10.4 Traffic Policing

This topic covers the overview, availability, impact, and principle of traffic policing.
10.4.1 Overview
Definition
Traffic policing (also called traffic policy) is used to limit the traffic volume and address the burst of a certain incoming connection on a network by measuring the arrival rate of traffic streams. When the packets meet certain conditions, for example, when the traffic of a connection is too heavy, traffic policing takes different actions, such as dropping the packets, or coloring the packets (re-setting the priority of the packets). The common method is to limit the traffic of one type of packets using the CAR, for example, set the HTTP packets to occupy no more than 50% network bandwidth only. In a PON system, upstream bandwidth conflict between ONUs is resolved by the DBA technology.
Purpose
The purposes of traffic policing are as follows: l l
Issue 01 (2011-10-30)
To ensure that the user traffic meets the service level agreement (SLA). To adjust the outgoing traffic and suppress the burst traffic for QoS guarantee.
10 QoS
To control the rate of broadcast packets through packet suppression.
The specifications of traffic policing are as follows: l l l l l l l l l CAR based on the port CAR based on the traffic stream CAR based on port+priority CAR based on port+VLAN (HQoS) on the SPUA board CAR using the trTCM algorithm (RFC2698) Priority-based CAR (enhanced based on CAR using the trTCM algorithm) Color-based early drop CAR based on the HQoS user group (the CAR group supports color-based CAR) A maximum of 512 IP traffic profiles defined in MEF10
10.4.3 Availability
Relevant NEs
The traffic policing feature involves only the MA5600T/MA5603T.
License Support
The traffic policing feature does not require a license.
Version Support
10.4.4 Traffic Policing Principle

In traffic policing, the committed access rate (CAR) is generally used to limit the traffic of packets using the token bucket (TB) algorithm. The MA5600T/MA5603T supports CAR based on the port or traffic stream.
Traffic Policing Based on Port

CAR uses TB for traffic control. Each packet must use the tokens equal to the packet length for transmission. As shown in the following figure, traffic policing is implemented as follows: Packets are classified. Then, packets of a certain type, after being specified with the traffic feature, enter the TB for processing. If the TB stores sufficient tokens, packets are transmitted. If the TB stores insufficient tokens, packets are dropped. In this way, the system controls the traffic of packets of a certain type.
10 QoS
The system generates tokens to the TB at a specified rate. In addition, the TB has a specified capacity. When the TB is full of tokens, the system suspends token generation until a token is used. Packet transmission consumes a certain number of tokens. The consumption of tokens depends on the packet length. When the remaining tokens in the TB are insufficient for transmitting a packet, the system drops the packet. A TB is a good tool for traffic control. When the TB is full of tokens, the system can transmit all the packets represented by the tokens. In this way, the system allows for burst transmission. When the TB is empty of tokens, the system transmits no packets. The system resumes the transmission only after a new token is generated. In this way, the rate of traffic transmission is limited to be lower than or equal to that of token generation. Figure 10-7 TB principle
Save the token in the token bucket at the specified rate. Packets to be transmitted through the interface Transmit the packet continuously.
Classification Token bucket
Discard
l l
For the Ethernet port, run the line-rate command to limit the upstream and downstream rates of the port. For the xDSL port, change the upstream and downstream rates in the line profile to limit the rate of the port.
Traffic Policing Based on Traffic Stream

Traffic policing based on the traffic stream is to monitor the traffic of each traffic stream. A traffic stream can be bound to a traffic profile, through which the CAR value of the traffic stream is defined. In traffic policing based on the traffic stream, two rate three color marker (trTCM) can be implemented using two TBs. As defined in RFC2698, trTCM is a marker, which can be used as a component in a Diffserv traffic conditioner and is used to meter and mark IP packet streams. Because the MA5600T/MA5603T implements the QoS technology at the Ethernet layer, the MA5600T/MA5603T does not support marking of IP packet headers but supports marking of Ethernet frame headers. The related parameters are as follows: l l
Issue 01 (2011-10-30)
CIR: committed information rate, in the unit of bytes/s. CBS: committed burst size, in the unit of bytes.
10 QoS
l l l
PIR: peak information rate, in the unit of bytes/s. PIR must be larger than or equal to CIR. PBS: peak burst size, in the unit of bytes. CM: color mode, with options color-blind and color-aware, which indicates whether or not to identify the colors of the incoming packets. Currently, the MA5600T/MA5603T supports the color-blind mode, that is, the MA5600T/MA5603T does not identify the colors of the incoming packets.
trTCM can be used for traffic policing and marking to achieve more effective bandwidth management. Based on static bandwidth planning, trTCM can ensure the basic bandwidth (that is, CIR) for users. When the network is idle, the trTCM allows users to obtain extra bandwidth, that is, PIR. In this way, the utilization of network resources is improved. Figure 10-8 illustrates the principle of trTCM. trTCM uses the DEI bit to identify different colors. On the MA5600T/MA5603T, the CFI bit in the Ethernet 802.1Q serves as the DEI bit. l l l When the rate is higher than PIR, packets are marked red and are directly dropped. When the rate is higher than CIR but is lower than or equal to PIR, packets are marked yellow and the DEI bit is set to 1. When the rate is lower than or equal to CIR, packets are marked green and the DEI bit is set to 0.
Figure 10-8 trTCM principle

PIR CIR P bucket Colored green <= CBS CBS
Color-bind
<= PBS PBS
C bucket
Color-aware > PBS
> CBS Colored yellow
queue
The following describes the algorithm of two TBs. Assume that there are two independent TBs, P and C, with sizes PBS and CBS respectively. Tp (t) and Tc(t) represent the number of tokens in P and C respectively at time t. Initially (t = 0), P and C are full, that is, Tp(0) = PBS and c(0) = CBS. Then, Tp is increased by one for PIR times per second until reaching PBS and Tc is increased by one for CIR times per second until reaching CBS. l In the color-blind mode, when packets of B bytes arrive at time t, the following operations are performed: 1. If Tp(t) - B < 0, packets exceeding Tp(t) are marked red. Otherwise, the device proceeds to the next step.
Issue 01 (2011-10-30)
10 QoS
2. 3. l
If Tc(t) - B < 0, packets exceeding Tc(t) are marked yellow and Tp is decreased by B. Otherwise, the device proceeds to the next step. Packets are marked green and both Tp and Tc are decreased by B.
In the color-aware mode, when packets of size B bytes arrive at time t, the following operations are performed: 1. 2. 3. If the packets have been marked red or if Tp(t) - B < 0, packets are marked red. Otherwise, the device proceeds to the next step. If the packets have been marked yellow or if Tc(t) - B < 0, the packets are marked yellow and Tp is decreased by B. Otherwise, the device proceeds to the next step. Packets are marked green and both Tp and Tc are decreased by B.
Packet Suppression
Packet suppression refers to the suppression of broadcast, multicast, and unknown unicast packets. In normal conditions, broadcast, multicast, and unknown unicast packets are broadcast in a VLAN. The purpose of suppressing these packets is to prevent them from exhausting the network resources so as to avoid network congestion. The traffic-suppress command can be executed to set the suppression level of broadcast, multicast, or unknown unicast packets on a port. After the suppression level is set successfully, the system limits the traffic of the port according to the threshold of the corresponding traffic suppression level if the traffic control is enabled on the port. Then, the system will drop the traffic that exceeds the threshold.
10.4.5 DBA Principle

DBA Technology
The dynamic bandwidth assignment (DBA) technology controls the upstream bandwidth of ONTs to avoid upstream bandwidth conflict. In a GPON system, the OLT controls the upstream data traffic by sending authorization signals to ONTs. In a PON network, an effective TDMA mechanism is required to control the upstream traffic, so that data packets from multiple ONTs do not collide during upstream transmission. However, the collision-based mechanism requires QoS management in a passive ODN, which is physically impossible or causes severe efficiency loss. Due to the above-mentioned factors, a mechanism for management of the upstream GPON traffic has been the primary focus in standardization of GPON traffic management. It drives the development of the ITU-T G.983.4 recommendation, which defines the DBA protocol for management of the upstream PON traffic. Figure 10-9 illustrates the DBA principle. The GPON system controls the upstream traffic by allocating data authorization to each transmission container (T-CONT) inside an ONT. To determine the authorized bandwidth to be allocated to a T-CONT, the OLT needs to know the traffic status of the T-CONT. Each ONT reports its data status to the OLT through the DBRu or payload field in the upstream frames. After receiving the data status, the OLT, according to status of data to be transmitted on the ONTs, periodically updates the upstream BWmap information using the DBA algorithm and notifies all ONTs of the BWmap information through downstream frames. In this way, each ONT dynamically adjusts its upstream bandwidth according to its actually transmitted data traffic, thereby improving the utilization of upstream bandwidth.
Issue 01 (2011-10-30)
216
10 QoS
Figure 10-9 DBA principle

ONU DBA report Control plane BW Map T-CONT DBA algorithm logic OLT
Time slot
Data plane
Scheduler
DBA Profile
ONU upstream bandwidth control is implemented through the DBA profile bound to the TCONT. There are five types of T-CONTs. In upstream service scheduling, different types of TCONTs are selected according the service type. Each T-CONT bandwidth type has its own QoS feature, which is mainly represented by bandwidth guarantee, including fixed, assured, assured +maximum, maximum, and hybrid mode (corresponding to type1 to type5 in Table 10-5). Table 10-5 Five types of T-CONTs Bandwidth Type Fixed bandwidth Assured bandwidth Maximum bandwidth T-CONT Type Type1 X No Z=X Type2 No Y Z=Y Type3 No Y Z>Y Type4 No No Z Type5 X Y ZX+Y
NOTE
In Table 10-5, "X" indicates the fixed bandwidth, "Y" assured bandwidth, and "Z" maximum bandwidth.
10.5 ACL Policy

Using the preset access control list (ACL) policy, the system permits or refuses data packets to pass.
Issue 01 (2011-10-30)
217
10 QoS
10.5.1 Introduction
Definition
The access control list (ACL) policy defines a series of matching rules, with which the packets to be filtered are identified. The packets identified are permitted or refused to pass according to the preset rules.
Purpose
ACL-based traffic filtering is a prerequisite for quality of service (QoS). ACL together with QoS improves the system security.
Specifications of the ACL Feature
The specifications of the ACL feature are as follows: l l l l l l ACLs are numbered from 2000 to 5999, and an ACL with any of the 4000 numbers can be defined. The system supports a maximum of 64 ACLs, each supporting a maximum of 32 rules. Table 10-6 describes each type of ACL. Users can use any of the first 80 bytes in the packet to define the ACL rules. Multiple fields can be configured at the same time. The system supports setting of the ACL time segment. A maximum of 256 time segments can be set. The system supports issuing of ACL-based packet filtering entries to a port. A maximum of 256 ACL-based packet filtering entries can be issued. The system supports ACL-based packet filtering, traffic control, packet priority re-marking, packet redirection, packet mirroring, and packet statistics collection.
Table 10-6 ACL types Type Basic ACL Value Range 2000-2999 Feature The rules of a basic ACL can be defined only according to the Layer 3 source IP address and the fragment field, for analyzing and processing data packets.
Issue 01 (2011-10-30)
218
10 QoS
Type Advanced ACL
Value Range 3000-3999
Feature Compared with a basic ACL, an advanced ACL allows more accurate, richer, and more flexible definition of the rules according to the following information about data packets: l Source address l Destination address l IP bearer protocol types 0-255 (GRE, ICMP, IP, IP in IP, TCP, and UDP) l TCP source port l TCP destination port l ICMP protocol type l ICMP code l Priority TOS/IP precedence/DSCP
Link layer ACL
4000-4999
The rules of a link layer ACL can be defined according to the following information: l MAC address l VLAN ID l Layer 2 protocol type l Destination MAC address l 802.1p priority
User-defined ACL
5000-5999
The rules of a user-defined ACL can be defined according to any 32 bytes of the first 80 bytes in a Layer 2 frame. l For IPoE packets: IPoE packets with no VLAN tag, one VLAN tag, or two VLAN tags can be matched. l For non-IPoE packets: Non-IPoE packets with any number (0, 1, 2, or more) of VLAN tags (0, 1, 2, or more) are be matched.
10.5.3 Availability
License Support
The ACL feature does not require a license.
Issue 01 (2011-10-30)
219
10 QoS
Version Support
Feature Dependency
1.VLAN-based ARP packet capture in V800R009 occupies more ACL resources than in any earlier versions. Therefore, in V800R009, the number of configurable ACLs has the following limits: l l l l Maximum number of non-user-defined ACLs supported by SCUL: 248. Maximum number of user-defined ACLs supported by SCUL: 80. Maximum number of non-user-defined ACLs supported by SCUB: 753. Maximum number of user-defined ACLs supported by SCUB: 80.
If the number of ACLs configured exceeds the limits, the following issues may occur: (1) ACL configurations are lost, and (2) ACLs configured in an earlier version fail to be restored after a version upgrade to V800R009.
NOTE
SCUF and SCUN boards do not have these limits.
Hardware Support
No additional hardware is required for the ACL feature.
10.5.4 Principle
ACL-based Packet Processing
The system matches and processes the input packets according to the ACL rules: l If the packets match an ACL rule, they are performed with further QoS actions, including packet filtering, priority marking, port CAR, traffic control, traffic statistics, packet redirection, and packet mirroring. After being processed using the preceding QoS actions, the packets are forwarded and output. Packet filtering Determines whether to drop the packets according to whether the packets match an ACL rule. Priority marking Marks the priority of the packets that match an ACL rule, including ToS, DSCP, and 802.1p. Traffic control Controls traffic of the packets that match an ACL rule.
10 QoS
Port CAR Supports single-bucket (flow-based) CAR and dual-bucket two rate three color marker (trTCM) CAR. Traffic statistics Collects statistics of the packets that match an ACL rule, including the number of packets and number of bytes. Packet redirection Redirects the packets that match an ACL rule, that is, re-specifies the port that forwards the packets (the original port no longer receives or forwards packets.) Packet mirroring Performs traffic mirroring on the packets that match an ACL rule, that is, packet streams that match an ACL rule can be copied and output to other ports. l If the packets do not match an ACL rule, the packets are dropped or forwarded according to the definition of the ACL rule.
Figure 10-10 illustrates ACL-based packet filtering and processing. Figure 10-10 ACL-based packet filtering and processing
Packet filtering Priority tagging Traffic limiting Port rate limiting Input packet stream Match the packets with the ACL Output packet stream
Matching? No Discard Discarded packets Yes
Implement actions
ACL Matching Order

When a packet matches two or more ACL rules, the matching order is as follows: l l The priority of a user-defined rule is higher than that of any non-user-defined rules. If the rules are all user-defined rules or non-user-defined rules, and are issued to the physical port, the matching order is high priority to low priority. Once a rule matches the packets, the packets no longer match the subsequent rules. If the rules of an ACL are activated at the same time, the rule with a larger rule-id has a higher priority. If the rules of an ACL are activated one by one, the rule activated later has a higher priority than the one activated earlier. If the rules are issued to the port from different ACLs, the rule activated later has a higher priority than the one activated earlier.
10 QoS
If the rules are all user-defined rules or non-user-defined rules, and are issued to the routing interface or firewall, the rule with a smaller rule-id has a higher priority. It is irrelevant the activation sequence. The rules are used to match the packets based on rule-id in ascending order. Once the rule with a smaller rule-id matches the packets, its subsequent rules are not used. That is, the rules with a larger rule-id are invalid.
10.6 Congestion Avoidance and Management

This topic covers the overview, specifications, availability, and principle of congestion avoidance and management.
10.6.1 Overview
Definition
When congestion occurs, the system takes a series of QoS actions to process the packets that cause congestion. Such a series of actions is congestion avoidance and management. Generally, congestion avoidance is implemented using the early drop algorithm, and congestion management is implemented through queue scheduling.
Purpose
Congestion avoidance and management is to differentiate the priorities of services and process packets with higher priorities first when congestion occurs in the system.
The specifications of congestion avoidance and management are as follows: Congestion avoidance: l l Color-based early drop Priority-based early drop
Congestion management: l Three queue scheduling modes: PQ (priority queuing), WRR (weighted round robin), and PQ+WRR
10.6.3 Availability
Relevant NEs
The congestion avoidance and management feature involves only the MA5600T/MA5603T.
License Support
The congestion avoidance and management feature does not require a license.
Issue 01 (2011-10-30)
222
10 QoS
Hardware support
Table 10-8 Hardware support (For Congestion Avoidance) Board CAME, OPGD, SPUA, VDPM, VDPE, VDRD, VDMF, ADPD, SHLM, OPFA GPON boards Color-based Early Drop Supported Priority-based Early Drop Not supported
Supported
Supported
Version Support
10.6.4 Congestion Avoidance Principle

Congestion avoidance is implemented by dropping unqualified packets in advance using an early drop algorithm (RED or WRED) in the case of congestion, so that bandwidth for qualified services is ensured. Congestion avoidance algorithms address the issue of global TCP synchronization caused by tail drop. In addition, color-based congestion avoidance algorithms ensure that green packets pass preferentially. l Tail drop: Tail drop is a first in first out (FIFO) queue management algorithm, with which packets are directly dropped when the maximum queue depth is reached. l RED: Users can set the lower threshold and upper threshold for queues. When the queue length is smaller than the lower threshold, no packets are dropped. When the queue length is between the lower threshold and the upper threshold, incoming packets are dropped randomly. A longer queue length indicates a higher drop probability. When the queue length exceeds the upper threshold, all newly arriving packets are dropped. Compared with tail drop, RED improves line bandwidth usage and reduces delay jitter if there are a large number of TCP packets. l WRED: Based on RED, WRED uses classification marks such as IP precedence, DSCP value, and MPLS EXP to differentiate drop policies. WRED effectively improves the service quality of packets with higher priority. Currently, the system supports the following two congestion avoidance algorithms: l
Issue 01 (2011-10-30)
Color-based early drop

10 QoS
Priority-based early drop
Color-based Early Drop

After the system marks packets in different colors (yellow and green; red packets are directly dropped) using the trTCM algorithm, these packets have different drop thresholds when entering a port queue. In this way, when the queue is not full although port congestion occurs, traffic configured with CIR (committed information rate) can pass while traffic configured with PIR (peak information rate) is dropped early. Currently, only SCUN, SCUB, SPUA, GPBD, and OPGD boards support color-based early drop. The drop threshold of yellow packets is 50% and green 100%. If more than 50% of a queue is occupied, yellow packets cannot enter the queue but green packets can. When the queue is 100% occupied, green packets are also dropped.
Priority-based Early Drop

Queues with different priorities can be configured with different drop thresholds. Specifically, queues with higher priorities are configured with higher drop thresholds, while queue with lower priorities are configured with lower drop thresholds. In this way, when port congestion occurs, packets with higher priorities can enter greater-depth, more burst-tolerant queues than packets with lower priorities and hence are less likely to be dropped. Currently, only H801GPBC, H802GPBD, H805GPBD, and H831HE1A boards support prioritybased early drop. The early drop depth of each queue is configurable.
10.6.5 Congestion Management Principle

Congestion management is to control traffic on a device using different algorithms for queue scheduling. Such algorithms include priority queuing (PQ) and weighted round robin (WRR). When congestion occurs on an egress, a proper queue scheduling mechanism can guarantee the QoS parameters (such as bandwidth, delay, and jitter) of a certain type of packets. The queue here refers to the outgoing queue. The queue is used to reserve packets in the flash memory until the egress is capable of transmitting packets. Therefore, the queue scheduling mechanism takes effect only when congestion occurs on an egress. The queue can also be used to re-prioritize packets, except FIFO. The features related to queue scheduling are as follows: Feature Classification Definition Checks packets and determines queues of the packets. Defines the rules for the device to drop packets. The commonly used drop policies are tail drop policy and WRED. Packets may be re-prioritized in a queue. In most cases, FIFO is used. Affected QoS Parameter N/A
Drop policy
Packet loss
Scheduling mode in one queue
Bandwidth, delay, jitter, and packet loss
Issue 01 (2011-10-30)
224
10 QoS
Feature Scheduling mode between queues Queue quantity Queue length
Definition Defines from which queue packets are taken out to the outgoing queue. Degree to which packets are classified. Maximum number of the packets that can be saved in one queue.
Affected QoS Parameter Bandwidth, delay, jitter, and packet loss N/A Packet loss and delay
The system supports the following three scheduling modes. Queue Scheduling Mechanism PQ WRR PQ+WRR Scheduling Mode Strict priority scheduling weighted round robin (WRR) scheduling Hybrid of priority queuing (PQ) and WRR scheduling
PQ is to put packets with different priorities to different queues for scheduling. All boards in the system support eight PQs, and they also support configuring of weights of PQs and mapping of packets with different priorities to a PQ.
PQ
PQ classifies packets and puts packets into the corresponding queues according to the packet classification result. PQ queues are classified into high-priority queues, medium-priority queues, normal-priority queues, and low-priority queues. PQ takes out all packets from a high-priority queue and transmits them. After such a transmission is completed, PQ performs the same on all packets in a medium-priority queue, a normal-priority queue, and a low-priority queue one by one. In this way, packets in a queue with a higher priority precede packets in a queue with a lower priority and therefore are processed preferentially, even in case of congestion. This ensures that packets for key services are processed first. Packets of non-key services (such as email) are processed only when the network is idle after key services are processed, thereby utilizing network resources efficiently.
Issue 01 (2011-10-30)
225
10 QoS
Figure 10-11 PQ
High Priority Queue7 Queue6 3 2 2 1 1

Queue3 Low Priority 2 1
PQ
When packets reach a port, they are classified first and are then put into the tail of the queues to which they belong according to the packet classification result. During packet transmission, the packets in the queue with a higher priority are always transmitted first. After that, the packets in the queue with a lower priority are transmitted. In this way, a short delay is ensured for the packets with a higher priority.
WRR
WRR classifies packets and places packets into the corresponding queues according to the packet classification result. WRR queues are assigned bandwidth on a port according to the bandwidth percentages defined by the user. When packets travel out of queues, WRR takes a certain number of packets from the queue and transmits them from the port according to the pre-defined bandwidth percentage. In WRR scheduling mode, the queues are scheduled in turn based on certain weight values, which ensures that each queue can be scheduled. When a queue is empty, the next queue is scheduled immediately. In this way, the bandwidth resources can be fully utilized. Figure 10-12 WRR
High Priority Queue7 Queue6 3 2 2 1 1 Assumed Weight: Q7:Q6:Q3=1:1:1 WRR 3 2 2 2 1 1 1

Queue3 Low Priority 2 1
Issue 01 (2011-10-30)
226
10 QoS
PQ+WRR
PQ+WRR is a combination of the PQ scheduling mode and WRR scheduling mode. When the weight value of a queue is 0, the queue scheduling mode is PQ+WRR. In this mode, the system schedules the queues with the weight value 0 in the PQ mode, and then schedules other queues in the WRR mode. With this flexible scheduling mode, the services that must be guaranteed are scheduled in the PQ mode, and the services with lower priorities are scheduled in the WRR mode when there is remaining bandwidth. In this way, services with higher priorities are ensured and those with lower priorities can obtain bandwidth when there is remaining bandwidth.
10.7 HQoS
In the conventional quality of service (QoS), traffic scheduling is based on the port. The hierarchical QoS (HQoS) is a QoS technology that controls user traffic on a port with finer granularity and also schedules services of a user based on the service priority.
10.7.1 Overview
Definition
HQoS is short for hierarchical quality of service. The conventional traffic management cannot ensure the bandwidth of each user on a port because bandwidth scheduling is based on the port. HQoS, however, ensures bandwidth of multiple services of multiple users at two levels. At the first level, the total bandwidth of each user is ensured. At the second level, the bandwidth of each service of each user is ensured. In general, HQoS is a QoS technology that controls user traffic on a port with finer granularity and also schedules services of a user based on the service priority. Currently, the system supports HQoS with the following three levels of bandwidth assurance: l HQoS user service: Services of one user but with different priorities. The priority here refers to the 802.1p priority. Services in this level can be scheduled in the PQ mode based on the priority. HQoS user: A bandwidth guarantee and scheduling unit. An HQoS user can be one or more access users. The total bandwidth of an HQoS user in this level is ensured, and when congestion occurs, the assured bandwidth configured for each HQoS user can be ensured. HQoS user group: A group of HQoS users. In this level, bandwidth limitation based on the HQoS user group is implemented. Currently, the system supports division of user groups based on upstream port+SVLAN (outer VLAN of the packet). All users with the same upstream port+SVLAN belong to one user group.
Purpose
HQoS aims to ensure bandwidth of multiple services for multiple users by controlling traffic of users and user services. It provides the committed information rate (CIR) and peak information rate (PIR) for different services of each user.
Benefit
Benefits to carriers: HQoS, which improves the port-based scheduling mode in the conventional QoS service, differentiates users on a port with finer granularity for QoS assurance. This enables carriers to
10 QoS
ensure QoS for the services of enterprises and subscribers and provide assured bandwidth and service packages for more users, thereby obtaining more profits. Benefits to users Compared with the conventional QoS, HQoS ensures bandwidth assigned for each user, without being interfered by other users.
The specifications of HQoS are as follows: l l l l l The data of each HQoS user is differentiated according to the four priorities for PQ scheduling. Upstream and downstream CIRs and PIRs can be set for each HQoS user. The system supports 1024 user groups and their upstream and downstream CIRs are configurable. The system supports traffic control based on the CAR group. One CAR group contains a maximum of eight traffic streams, but one traffic stream belongs to only one CAR group. The system supports a maximum of 16K CAR groups, and a PON board supports a maximum of 1K CAR groups.

The following lists the reference standards and protocols of this feature: RFC2698: A Two Rate Three Color Marker
10.7.4 Availability
License Support
The HQoS feature is an optional feature of the MA5600T/MA5603T, and the corresponding services are controlled by the license.
Version Support
Hardware Support
l l Only the PON boards support HQoS. HQoS based on the SVLAN priority requires cooperation with the SPUA board.
10.7.5 Principle of Priority-based HQoS

Figure 10-13 illustrates the model of priority-based HQoS supported by the MA5600T/ MA5603T. The HQoS user here refers to an end-to-end traffic stream.
10 QoS
The core of priority-based HQoS is to implement two-level CAR for services on the SPUA board. l l Level-1 CAR: Priority-based CAR is performed on HQoS users and traffic streams are colored. In this way, users' services are fairly scheduled and CIR of each user is ensured. Level-2 CAR: The same type of services in a CP is marked the same color for CAR (colorbased CAR), thereby preventing a single type of services from occupying all the bandwidth in a CP. In this way, different services are fairly scheduled to ensure CIR of each service, or even PIR if bandwidth permits.
Figure 10-13 Priority-based HQoS Model

Flow CAR for HQoS users
Flow 1 (Pri=P1) Flow 1 (Pri=P2)
CAR for one type of service in a CP
Represents a CP
Traffic streams with different priorities
Flow
Port+VLAN Port
Figure 10-14 illustrates the overall solution of priority-based HQoS on the SPUA board. Figure 10-14 Priority-based HQoS processing
(4) (2) Priority-based CAR for users (3)
(1) Traffic classification
7 6
Color-based CAR according to port+SVLAN
Processing of priority-based HQoS on the SPUA board is as follows: 1. Traffic classification HQoS users are differentiated based on port+SVLAN+CVLAN on the upstream board of the SPUA board. 2. Priority-based CAR for the HQoS user According to CIR and PIR of an HQoS user, packets of the user are marked different colors, which is implemented using the trTCM mechanism with four priority thresholds. Packets whose rate is lower than CIR are marked green, packets whose rate is within CIR and PIR yellow, and packets whose rate is higher than PIR are directly dropped. During coloring,
10 QoS
priority also counts, that is, packets with a higher priority can preferentially occupy CIR and PIR bandwidth. This can be regarded as virtual PQ scheduling.
NOTE
A virtual queue has the following characteristics: l Containing no actual buffer unit and buffering no data l No delay when data enters or leaves the queue l Functioning as one queue in the hierarchical scheduling for output scheduling
3.
Color-based CAR for the HQoS user group Green packets are allowed to pass, yellow packets that do not exceed the bandwidth can also pass, and yellow packets that exceed the bandwidth are dropped. Yellow packets cannot be upgraded to green packets.
4.
Port queue scheduling All HQoS users enter the same priority queue at the egress, and color-based early drop is implemented in the queue. In this way, when the congestion threshold is reached, the system starts dropping yellow packets to ensure a short delay of green packets. The queue here is a real queue on the port, and the port supports PQ and WRR scheduling of eight such queues. To ensure that all HQoS users enter the same priority queue, the following settings are adopted: In FTTB, HQoS users are generally tagged SVLAN +CVLAN and therefore priorities of SVLANs of these users are all set to a specified priority; in FTTH, HQoS users are generally tagged a single VLAN and therefore all priorities of the single VLANs of these users are mapped to the same queue.
NOTE
The system does not provide a command for setting the drop threshold of the yellow packets, but the existing command for setting the queue depth actually functions so. The smaller the depth, the lower the drop threshold of the yellow packets, and the earlier the yellow packets are dropped when congestion occurs.
10.7.6 Principle of HQoS Based on CAR Group

A CAR group is a combination of traffic streams for unified QoS control, with configurable parameters such as CIR and PIR. One of its typical applications is for multiple services (IPTV, Internet access, and voice services) of home users. Using the CAR group, QoS based on the home user instead of based on each service is implemented. Figure 10-15 illustrates the model of CAR-group-based HQoS supported by the MA5600T/ MA5603T. HQoS based on CAR group implements two-level or three-level CAR for services: l l l Level-1 CAR is performed for user traffic streams. Level-2 CAR is performed for multiple traffic streams of HQoS users (that is, CAR group). If necessary, level-3 CAR is performed, which is color-based CAR for HQoS user groups. Currently, the system supports classifying of user groups by upstream port+SVLAN (outer VLAN of the packet).
For example, the two-level CAR can achieve the following settings: limiting a user's Internet access rate, multicast service rate, and voice service rate to 2 Mbit/s, 4 Mbit/s, and 128 Kbit/s respectively, and at the same time limiting the total bandwidth of the user to 5 Mbit/s.
Issue 01 (2011-10-30)
230
10 QoS
Figure 10-15 Model of HQoS based on CAR group
HQoS user service Flow 1 Flow 2 Flow CAR
HQoS user
HQoS user group
CAR based on multiple traffic streams (CAR group)
CAR based on multiple users
Application Scenario
A CAR group can also be used for RSPs, as shown in the following figure. Figure 10-16 Application scenario of CAR group
tag RSP1 a RSP1 b RSP1 a untag QinQ OLT tag RSP1 a RSP2 b RSP2 c untag QinQ ONT RSP2 RG ONT RSP1
a b c
a b c d a
tag RSP1 a RSP2 a RSP3 a untag QinQ ONT RSP3
b c d
RSP: retail service provider
RG: residential gateway
As shown in the preceding figure, users under the same ONT may belong to different RSPs. Different services of the same user are mapped to different traffic streams on the OLT. Given that different service CIRs/PIRs are guaranteed, the total bandwidth of each RSP needs to be
10 QoS
ensured and each service should be allowed to occupy the total bandwidth when a burst occurs in the traffic. To put it simply, rate limitation needs to be performed on the RSP. To do so, a group based on all traffic streams of an RSP can be created, and then the total bandwidth of a user can be limited by limiting the bandwidth of the group. Such is a typical application of CAR group.
Principle
In the upstream direction Figure 10-17 Principle of CAR group (in the upstream direction)
Gem CAR TCONT Flow CAR (trTCM) GPON gem1+c1 Flow1(S+C1) gem2+c2 Flow2(S+C2) gem3+c3 Flow3(S+C3) gem4+c3 Flow4(S+C3) gem5+untag Flow5(S1+C1) RSP2 Flow Group CAR Color-based early drop PQ scheduling of port queues SCU RSP1
RG RSP1 RG RG
C1 C2 C3 C1 C2 C3 C1 C2 C3
ONT
RSP2
STB
untag
RSP: retail service provider STB: set-top box trTCM: two rate three color marker
RG: residential gateway GEM: G-PON encapsulation method
The processing of implementing QoS of upstream traffic streams on the OLT is as follows: l trTCM CAR for traffic streams: The OLT identifies the packets of the specified traffic streams. The OLT colors the packets according to CIR/PIR. Specifically, for the packets whose rate is equal to or lower than CIR, the OLT marks them green (allowed to pass). For the packets whose rate is higher than CIR and lower than PIR, the OLT marks them yellow (allowed to pass). For the packets whose rate is higher than PIR, the OLT drops such packets. l Color-based CAR for flow groups: The OLT identifies the packets of all traffic streams in a flow group. The OLT supports single leaky bucket and supports a threshold for dropping yellow packets to ensure that all green packets are passed. Such can be achieved on the condition that the group PIR configured by the user is larger than the total CIRs of all traffic streams.
10 QoS
PQ scheduling and color-based early drop on the upstream port: The OLT schedules packets on the upstream port according to the packet priorities. Packets with a higher priority are scheduled first. The OLT performs color-based early drop to ensure that all green packets among the packets with the same priority are passed.
NOTE
The QoS guarantee processing of the packets in the downstream direction is reverse to that in the upstream direction.
The principles of implementing QoS of upstream traffic streams on the ONT and the OLT are as follows: l ONT The LSW port on the ONT supports PQ scheduling but does not support color-based early drop. When packet congestion occurs on the LSW upstream port, the ONT performs tail drop on the packets. On the ONT, the same type of services of an RSP is mapped to one GEM port, and CAR (single leaky bucket CAR) is performed based on the GEM port. Each GEM port is bound to a T-CONT and the bandwidth of each type of services is guaranteed through the T-CONT. PQ scheduling is performed on the T-CONT (the service CoS priority must be consistent so as to avoid differences in scheduling). l GPON board Each GEM port+CVLAN is mapped to a traffic stream. In the trust mode, the CVLAN CoS priority is copied to the SVLAN; in the un-trust mode, the priority is specified. trTCM CAR is performed on each traffic stream. Color-based two-level CAR (single leaky bucket; supporting a threshold for dropping yellow packets; identifying the color but not the priority) is performed on all stream groups belonging to a user. In the configuration, the following must be ensured: PIR of the stream group CAR total CIRs of all traffic streams. The GPON board performs PQ scheduling and color-based early drop on the upstream port. l SCUN board The SCUN board performs PQ scheduling and color-based early drop on the upstream port. In the downstream direction
Issue 01 (2011-10-30)
233
10 QoS
Figure 10-18 Principle of CAR group (in the downstream direction)

Gem CAR Flow Group Flow CAR (trTCM) CAR GPON gem1+c1 Flow1(S+C1) gem2+c2 Flow2(S+C2) gem3+c3 Flow3(S+C3) gem4+c3 Flow4(S+C3) gem5+untag Flow5(S1+C1) RSP2 Color-based early drop PQ scheduling of port queues SCU RSP1
RG RSP1 RG RG
C1 C2 C3 C1 C2 C3 C1 C2 C3
ONT
RSP2
STB
untag
Color-based early drop PQ scheduling of port queue
The principles of implementing QoS of downstream traffic streams on the ONT and the OLT are as follows: l SCUN board The SCUN board performs PQ scheduling and color-based early drop on the LSW downstream port, and trusts the CoS priority of downstream packets. Downstream packets need to be colored on the upper-layer device. In actual networks, the upper-layer routers do not support coloring of the packets. In this case, if congestion occurs on the LSW port of the SCUN board, tail drop is performed on the downstream port. It is recommended not to aggregate ports for upstream transmission, and it is recommended to control the downstream traffic of each PON board below 10GE, so as to avoid congestion on the LSW downstream port. l GPON board trTCM CAR is performed on each traffic stream. Color-based two-level CAR (single leaky bucket; supporting a threshold for dropping yellow packets) is performed on flow groups. In the configuration, the following must be ensured: PIR of the stream group CAR total CIRs of all traffic streams. The GPON board performs PQ scheduling and color-based early drop on the egress. l ONT CAR is performed on GEM ports. PQ scheduling is performed on the LSW egress on the ONT. When packet congestion occurs on the port, the ONT performs tail drop on the packets.
Issue 01 (2011-10-30)
234

NOTE
10 QoS
l One traffic stream can belong to only one group; one group can contain a maximum of eight traffic streams; all traffic streams of a group belong to the same PON port. l The CAR group supports the Type B and Type D protection scenarios. Type D protection switching is based on the ONT. In inter-board protection, to maintain consistency of the data of the two mutually-protected PON boards, the CAR group feature and the Type D feature are required to be mutually exclusive based on the ONT checking. That is, when Type D protection is configured on the ONT, the traffic streams of this ONT and the traffic streams of other ONTs must not belong to the same CAR group and must not be added to the same CAR group.
10.8 QoS Network Application

QoS applications in different networks are similar. The main difference lies in carriers' traffic control requirements, such as requirements for traffic control points. The following describes two typical QoS applications in FTTx.
10.8.1 Typical QoS Application in an FTTH/P2P Network

Figure 10-19 illustrates the typical QoS application in an FTTH/P2P network. In a PON system, QoS is implemented in the following aspects: l l l The upstream bandwidth of ONTs is controlled through DBA. On the OLT, CAR is implemented for traffic streams of VoIP and Internet access services and then CAR-group-based control is implemented for users, achieving HQoS. Generally, the priorities of the VoIP service, multicast service, and Internet access service are configured in descending order.
Figure 10-19 Typical QoS application in an FTTH/P2P network

DHCP server VoIP Video VLAN 100 VLAN 200 300 T-CONT 1 GEM 128 GEM 129 GEM 130 L2/L3 network VPN n S+C: 900: 1 901 902: 1 Flow CAR CAR Group VoIP traffic Video traffic Internet traffic RSP n S+C: 800: 1 801 802: 1
VPN 1
RSP1
VLAN HGW PPPoE/DHCP VoIP
UNI port
Upstream Port
Video VLAN 400 VLAN 500 VLAN HGW PPPoE/DHCP 600
T-CONT 2 GEM 131
GEM 132 GEM 133 ONT OLT
SVLAN: Per service per SP CVLAN: Per customer
Based on the preceding network, Table 10-11 provides the VLAN data plan, Table 10-12 QoS data plan, and Table 10-13 service bandwidth data plan.
10 QoS
Table 10-11 VLAN data plan in an FTTH/P2P network SVLAN is the VLAN of a certain service in an RSP, CVLAN is the VLAN of a user, and XVLAN is a user-side VLAN for service differentiation. RSP RSP 1 Service VoIP Multicast Internet RSP 2 VoIP Multicast Internet CVLAN 800 801 802 900 901 902 SVLAN 1 N/A 1 1 N/A 1 XVLAN 100 200 300 400 500 600
Table 10-12 QoS data plan in an FTTH/P2P network Queue Scheduling Mode PQ+WRR Service VoIP Multicast Internet access Priority 6 4 2
Table 10-13 Bandwidth data plan in an FTTH/P2P network RSP Service Service Bandwidth 100 Mbit/s User Upstream Bandwidth CIR: 128 kbit/s PIR: 128 kbit/s Multicast Internet access 400 Mbit/s 500 Mbit/s N/A CIR: 2 Mbit/s PIR: 4 Mbit/s RSP 2 VoIP 100 Mbit/s CIR: 128 kbit/s PIR: 128 kbit/s Multicast Internet access 200 Mbit/s 700 Mbit/s N/A CIR: 2 Mbit/s PIR: 4 Mbit/s User Downstream Bandwidth CIR: 128 kbit/s PIR: 128 kbit/s N/A CIR: 5 Mbit/s PIR: 10 Mbit/s CIR: 128 kbit/s PIR: 128 kbit/s N/A CIR: 10 Mbit/s PIR: 20 Mbit/s
RSP 1
VoIP
Issue 01 (2011-10-30)
236
10 QoS
10.8.2 Typical QoS Application in an FTTB/FTTC Network

Figure 10-20 illustrates the typical QoS application in an FTTB/FTTC network. In a PON system, QoS is implemented in the following aspects: l l l l Generally, no traffic control is performed on the modem. On the ONU, CAR is implemented for traffic streams of VoIP and Internet access services and upstream bandwidth is controlled through DBA. On the OLT, no bandwidth limitation is required for user services. Generally, the priorities of the VoIP service, multicast service, and Internet access service are configured in descending order.
Figure 10-20 Typical QoS application in an FTTB/FTTC network

DHCP server VoIP Video VLAN 100 VLAN 200 VLAN 300 PPPoE/DHCP VoIP Video VLAN 400 VLAN 500 VLAN 600
HGW HGW
S+C: 800: 1 801 802: 1
S+C: 800: 1 801 802: 1
VPN 1
RSP1
UNI Port
Upstream Port
Upstream Port
L2/L3 network VPN n RSP n
PPPoE/DHCP
Modem
S+C: 900: 1 901 902: 1 DSLAM
S+C: 900: 1 901 902: 1 OLT Flow CAR VoIP traffic Video traffic Internet traffic
S VLAN: Per service per SP C VLAN: Per customer
Based on the preceding network, Table 10-14 provides the VLAN data plan, Table 10-15 QoS data plan, and Table 10-16 service bandwidth data plan. Table 10-14 VLAN data plan in an FTTB/FTTC network SVLAN is the VLAN of a certain service in an RSP, CVLAN is the VLAN of a user, and XVLAN is a user-side VLAN for service differentiation. RSP RSP 1 Service VoIP Multicast Internet RSP 2 VoIP Multicast
Issue 01 (2011-10-30)
CVLAN 800 801 802 900 901
SVLAN 1 N/A 1 1 N/A
XVLAN 100 200 300 400 500

237
10 QoS
RSP
Service Internet access
CVLAN 902
SVLAN 1
XVLAN 600
Table 10-15 QoS data plan in an FTTB/FTTC network Queue Scheduling Mode PQ+WRR Service VoIP Multicast Internet access Priority 6 4 2
Table 10-16 Bandwidth data plan in an FTTB/FTTC network RSP Service Service Bandwidth 100 Mbit/s User Upstream Bandwidth CIR: 128 kbit/s PIR: 128 kbit/s Multicast Internet access 400 Mbit/s 500 Mbit/s N/A CIR: 2 Mbit/s PIR: 4 Mbit/s RSP 2 VoIP 100 Mbit/s CIR: 128 kbit/s PIR: 128 kbit/s Multicast Internet access 200 Mbit/s 700 Mbit/s N/A CIR: 2 Mbit/s PIR: 4 Mbit/s User Downstream Bandwidth CIR: 128 kbit/s PIR: 128 kbit/s N/A CIR: 5 Mbit/s PIR: 10 Mbit/s CIR: 128 kbit/s PIR: 256 kbit/s N/A CIR: 10 Mbit/s PIR: 20 Mbit/s
RSP 1
VoIP

This topic provides glossary, acronyms, and abbreviations relevant to the QoS feature.
Issue 01 (2011-10-30)
238
10 QoS
Glossary
Table 10-17 Glossary relevant to the QoS feature Term HQoS user Assured bandwidth Burst bandwidth Description An HQoS user, which does not map an actual access user, is a bandwidth guarantee and scheduling unit. An actual access user can map one or more HQoS users, which is determined by the specific service planning. When a user is provided with the assured bandwidth, all the traffic within this bandwidth is allowed to pass. Burst bandwidth refers to the user's traffic that is allowed to exceed the assured bandwidth. The traffic within this bandwidth can pass a port when the port has remaining bandwidth.

Table 10-18 Acronyms and abbreviations relevant to the QoS feature Acronym/ Abbreviation ONT ONU ODN HQoS CIR PIR CAR CP trTCM PQ WRR WFQ CoS ToS DBA ACL Full Name optical network terminal Optical Network Unit optical distribution network hierarchical quality of service committed information rate peak information rate committed access rate content provider two rate three color marker priority queuing weighted round robin Weighted Fair Queuing Class of Service Type of Service Dynamic Bandwidth Allocation Access Control List
Issue 01 (2011-10-30)
239
10 QoS
Acronym/ Abbreviation WRED
Full Name Weighted Random Early Detection
Issue 01 (2011-10-30)
240
11 Layer 3 Features
11
About This Chapter
Layer 3 Features
This topic describes the network layer (Layer 3) features implemented by the system. 11.1 ARP The Address Resolution Protocol (ARP) is a protocol which is used to convert an IP address to a MAC address. This topic provides introduction to this feature and describes the principle and reference documents of this feature. 11.2 ARP Proxy ARP proxy is a process of handling the ARP requests. This topic provides introduction to this feature and describes the principle and reference documents of this feature. 11.3 DHCP Relay Dynamic Host Configuration Protocol (DHCP) relay enables DHCP clients in different physical subnets to obtain IP addresses that are dynamically allocated from the same DHCP server. 11.4 DHCP Proxy DHCP proxy is a mechanism in which the MA5600T/MA5603T acts as a proxy for processing the DHCP packets exchanged between a DHCP server and a DHCP client. That is, the MA5600T/MA5603T modifies the DHCP packets based on the requirements. 11.5 IP-aware Bridge 11.6 VRRP Snooping VRRP is a fault-tolerant protocol. It allows multiple routers to form a virtual routing device, and provides a mechanism, which ensures that services will be taken over in time by another device once the next hop of a host fails. In this way the continuity and reliability of communication are ensured. VRRP snooping is to snoop (or listen for) VRRP packets. 11.7 Routing Routing is a common term used for describing the path through which the packets from a host in a network travel to a host in another network.
Issue 01 (2011-10-30)
241
11 Layer 3 Features
11.1 ARP
The Address Resolution Protocol (ARP) is a protocol which is used to convert an IP address to a MAC address. This topic provides introduction to this feature and describes the principle and reference documents of this feature.
11.1.1 Introduction
Definition
The Address Resolution Protocol (ARP) is a protocol which is used to convert an IP address to a MAC address. It belongs to the TCP/IP protocol suite.
Purpose
The IP address represents only the network layer address of a host. If a host in a network needs to send the network layer data to a destination host, the host must know the physical address (MAC address) of the destination host. Therefore, an IP address has to be translated into a MAC address. ARP is used for translating an IP address to a MAC address.
When using SCUN, the MA5600T/MA5603T supports 8192 ARP entries, including 512 static entries and 7680 dynamic entries. When using SCUL, the MA5600T/MA5603T supports 4096 ARP entries, including 512 static entries and 3584 dynamic entries. When using SCUB, the MA5600T/MA5603T supports 8192 ARP entries, including 512 static entries and 7680 dynamic entries.

The following lists the reference documents of ARP: l IETF RFC 826: An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware
11.1.4 Availability
License Support
The ARP feature is the basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Issue 01 (2011-10-30)
242
11 Layer 3 Features
Version Support
Hardware Support
No additional hardware is required for supporting the ARP feature.
11.1.5 Principle
ARP Mapping List
Every host has a table named the ARP mapping list for converting IP addresses into MAC addresses. The ARP mapping list of a host contains a series of mappings between IP addresses and associated MAC addresses of other hosts that have communicated with this host recently. When a host is started, its ARP mapping list is empty.
Implementation of ARP
ARP enables two hosts in a network to interconnect with each other at Layer 2. Assume that there are two PCs: host A and host B with IP addresses IP_A and IP_B respectively. Host A sends messages to host B in the following way: 1. Host A checks its ARP mapping list for the ARP mapping entry of IP_B. l If host A finds the MAC address of host B, host A encapsulates the IP data packets according to the MAC address and then sends them to host B. l If host A does not find the MAC Address of host B, host A puts the data packets in the ARP waiting queue, initiates an ARP request, and then broadcasts it on the Ethernet. The ARP request contains the IP address of host B and the IP address and MAC address of host A. 2. 3. 4. 5. As the ARP request is broadcasted, all the hosts on the Ethernet can receive it. Only the requested host (host B), however, responds to the request. Host B stores the IP and MAC addresses of the request initiator (host A) contained in the request, in its own ARP mapping list. Host B returns an ARP response containing the MAC address of host B to host A. Such a response is no longer broadcast, but sent to host A directly. After receiving the response, host A extracts the IP address and MAC address of host B, and adds them to its own ARP mapping list. After that, host A transmits all the data packets in the waiting queue destined for host B.
Issue 01 (2011-10-30)
11 Layer 3 Features
Static ARP and Dynamic ARP

The manually configured mapping between IP addresses and MAC addresses is known as the static ARP. The mapping between IP addresses and MAC addresses configured dynamically by the ARP protocol is known as the dynamic ARP. In general, the dynamic ARP is needed. The static ARP is needed only when you need to manually adjust the ARP entries. A static ARP entry takes effect when the MA5600T/MA5603T works, while the aging time for a dynamic ARP entry is configurable, the default value is 20 minutes.
11.2 ARP Proxy

ARP proxy is a process of handling the ARP requests. This topic provides introduction to this feature and describes the principle and reference documents of this feature.
11.2.1 Introduction
Definition
When a host sends an ARP request to another host, the request is processed by the access device connected to the two hosts. This process is called ARP proxy.
Purpose
On the MA5600T/MA5603T, ARP proxy is often used for interconnection between sub VLANs in a super VLAN.
The MA5600T/MA5603T supports ARP proxy. The MA5600T/MA5603T supports to reply to the ARP request sent from network side (by the edge router).

The following lists the reference documents of ARP proxy: l IETF RFC1027: Using ARP to Implement Transparent Subnet Gateways
11.2.4 Availability
License Support
The ARP proxy feature is the basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Issue 01 (2011-10-30)
244
11 Layer 3 Features
Version Support
Hardware Support
No additional hardware is required for supporting the ARP proxy feature.
11.2.5 Principle
As shown in Figure 11-1, PC 1 is in sub VLAN 1, and PC 2 is in sub VLAN 2. They are isolated at Layer 2. PC 1, PC 2 and the virtual Layer 3 interface are in the same subnet. Figure 11-1 Implementation of the ARP proxy
communication Super VLAN Virtual interface Gateway IP: 1.1.1.1/24 MAC: 00-e0-fc-00-00-11 AR P Pr ox y Sub VLAN 2
Layer 3
P AR
Layer 2 Sub VLAN 1
ox Pr
Isolation
PC1 IP: 1.1.1.2/24 MAC: 00-e0-fc-00-00-02
PC2 IP: 1.1.1.15/24 MAC: 00-e0-fc-00-00-15
The following describes how PC 1 and PC 2 communicate with each other. 1. Because PC 1 and PC 2 are in the same subnet, when PC 1 attempts to send packets to PC 2, it broadcasts ARP packets directly to request the MAC address of PC 2. Because PC 1 and PC 2 are in different broadcast domains, PC 1 does not receive the ARP response packet from PC 2.
Issue 01 (2011-10-30)
245
11 Layer 3 Features
2.
When the MA5600T/MA5603T with the ARP proxy enabled receives the ARP request packets, it sends the MAC address of its virtual Layer 3 interface to PC 1, and searches its ARP mapping list for the MAC address of PC 2. If the ARP mapping list contains the MAC address of PC 2, the packets from PC 1 can be forwarded to PC 2 through the virtual Layer 3 interface. If the ARP mapping list does not contain the MAC address of PC 2, the MA5600T/ MA5603T broadcasts the ARP request packets through its virtual Layer 3 interface to request the MAC address of PC 2. When the MA5600T/MA5603T receives the ARP response packets from PC 2, the MA5600T/MA5603T adds the MAC address of PC 2 to its ARP mapping list. After this, the implementation of the ARP proxy is complete, and PC 1 and PC 2 communicate with each other through the MA5600T/MA5603T.
3. 4.
5.
11.3 DHCP Relay

Dynamic Host Configuration Protocol (DHCP) relay enables DHCP clients in different physical subnets to obtain IP addresses that are dynamically allocated from the same DHCP server.
11.3.1 Introduction
Definition
Dynamic Host Configuration Protocol (DHCP) relay is a process in which cross-subnet forwarding of DHCP packets is implemented between the DHCP client and the DHCP server. DHCP relay enables DHCP clients in different physical subnets to obtain IP addresses that are dynamically allocated from the same DHCP server.
Purpose
DHCP works in client-server mode. l l The DHCP client dynamically requests the configuration data from the DHCP server. The DHCP server dynamically allocates the data including the IP address to the client.
DHCP was initially only suitable for the applications where the DHCP client and the DHCP server were located on the same subnet and could not work across the subnet. Each subnet had to be configured with a DHCP server, which was uneconomical. The introduction of DHCP relay solves this problem. DHCP relay serves as a relay between the DHCP client and the DHCP server, which are located on different subnets. With DHCP relay, DHCP packets can be relayed to the destination DHCP server or client across subnets. In this way, multiple DHCP clients on different networks can use the same DHCP server. This is economical and convenient for centralized management.
The MA5600T/MA5603T supports the following DHCPv4 relay specifications: l l DHCPv4 Layer 2 and Layer 3 relay A maximum of 20 DHCPv4 server groups, with an active DHCPv4 server and 1-3 standby DHCPv4 servers in each group
Issue 01 (2011-10-30)
11 Layer 3 Features
Selection of a DHCPv4 server in the following three modes when the MA5600T/ MA5603T implements Layer 3 relay: DHCPv4 Standard mode DHCPv4 option 60 mode MAC address segment mode
l l
A maximum of 128 DHCPv4 option 60 domains A domain name is a case-insensitive character string of 1-32 characters. A maximum of 128 MAC address segments The name of a MAC address segment is a case-insensitive character string of 1-32 characters.
A maximum length of 253 bytes for RID and CID character strings

The DHCP relay feature complies with the following reference standards and protocols: l l RFC 2131: Dynamic Host Configuration Protocol DHCPv4 option 82: RFC 3046
11.3.4 Availability
License Support
The DHCP relay feature is an optional feature of the MA5600T/MA5603T. A license is required for this feature.
Version Support
Table 11-3 Version support for DHCPv4 relay Product MA5600T/ MA5603T Version V800R006C02 and later versions
Feature Dependency
The DHCP relay can be enabled globally or within a VLAN, but cannot be enabled for a board or a port.
Hardware Support
No additional hardware is required for supporting the DHCPv4 relay feature.
Issue 01 (2011-10-30)
247
11 Layer 3 Features
Restrictions
l Connection-oriented traffic streams do not support Layer 3 forwarding, and therefore do not support DHCP Layer 3 relay. If the global DHCP working mode is set to Layer 3 mode, connection-oriented traffic streams transparently transmit DHCP packets at Layer 2. DHCP Layer 3 relay is mutually exclusive with flow bundle, stacking VLAN, and S-VLAN +C-VLAN forwarding.
11.3.5 DHCPv4 Layer 2 Relay Principle

When routing is not available or is disabled on an access device, the device serves only as a bridge device. If some options (for example, option 82, that is, relay agent information option, interface ID option, and remote ID option) that identify user-side interfaces need to be inserted into DHCP messages, DHCP Layer 2 relay is required for the access device. If a DHCPv4 relay agent is used for a DHCPv4 client to send a request to the DHCPv4 server, the DHCPv4 relay agent adds the option 82 into the request. Option 82 supports the proxy of the circuit ID and remote ID, which records the address information of the DHCPv4 client and DHCPv4 relay agent on the DHCPv4 server. When this feature works with other software, DHCPv4 allocation restriction and accounting can be implemented. 1. 2. 3. A DHCPv4 client broadcasts a request when it is initialized. If there is a DHCPv4 server on the LAN, the DHCPv4 client can obtain the IPv4 address directly from the DHCPv4 server. If there is no DHCPv4 server on the LAN, the DHCPv4 relay agent device connected to the LAN processes the request. The DHCPv4 relay agent checks the request for the option 82, and then processes the request in the following ways: l If there is option 82 in the request, the DHCPv4 relay agent processes the request according to the configured policy (replacing the request's option 82 with the relay agent's option 82 or retaining the request's original option 82), and then forwards the request to the DHCPv4 server. l If there is no option 82 in the request, the DHCPv4 relay agent adds its option 82 to the request and forwards the request to the DHCPv4 server.The request contains the MAC address and VLAN of the switch port to which the DHCPv4 client is connected and the MAC address of the DHCPv4 relay agent. 4. After receiving the DHCPv4 request forwarded by the DHCPv4 relay agent, the DHCPv4 server records the information carried in the option field of the request, and then sends the reply packet that carries the DHCPv4 configuration and option 82 back to the DHCPv4 relay agent. After receiving the reply packet from the DHCPv4 server, the DHCPv4 relay agent removes the option 82 from the packet, and then forwards the packet carrying only the DHCPv4 configuration to the DHCPv4 client.
5.
11.3.6 DHCPv4 Layer 3 Relay Principle

1. 2. When a Dynamic Host Configuration Protocol (DHCP) client starts and initializes DHCPv4, it broadcasts the configuration request message on the local area network (LAN). If there is a DHCPv4 server on the LAN, DHCPv4 can be directly configured without the need of DHCPv4 relay.
Issue 01 (2011-10-30)
248
11 Layer 3 Features
3.
If there is no DHCPv4 server on the LAN, the DHCPv4 relay-enabled device connected to the LAN receives the broadcast packets. The device properly processes the packets and forwards them to a specified DHCPv4 server on another network. The DHCPv4 server configures a DHCPv4 client based on the client's information, and then sends the configuration information to the client. In this way, a DHCPv4 client is dynamically configured.
4.
The MA5600T/MA5603T supports selection of the DHCPv4 server group in the following three modes: l DHCPv4 relay standard mode The DHCP server group is selected based on the interface for receiving DHCP packets. The DHCP server group to which the interface is bound needs to be configured beforehand. In this mode, users are differentiated by VLAN. This is the most common and simplest DHCP relay mode. The disadvantage of this mode is that different service types in the same VLAN cannot be differentiated. This is the default mode in the system. l DHCPv4 option 60 mode The DHCPv4 server group is selected based on the character string (domain name) in the option 60 of DHCPv4 packets. The option 60 domain name and the DHCPv4 server group to which the domain name is bound need to be configured beforehand. In this mode, users are differentiated by the field information contained in the packets. This is a common DHCP relay mode, and in this mode, service types in the same VLAN can be differentiated. l MAC address segment mode The DHCP server group is selected based on the source MAC address of DHCP packets. The MAC address segment and the DHCPv4 server group to which the MAC address segment is bound need to be configured beforehand. In this mode, users are differentiated according to the source MAC address segment of the packets, and service types in the same VLAN can be differentiated.
11.3.7 Networking Application

Figure 11-2 shows the DHCP relay network diagram. Figure 11-2 DHCP relay network
Ethernet DHCP Relay Agent DHCP client DHCP server DHCP client MA5600T/ MA5603T DHCP server DHCP client
In a typical DHCP relay network, there are three roles:

11 Layer 3 Features
l l
DHCP client: A device that dynamically obtains IP addresses, or other network configuration parameters. DHCP relay agent: DHCP clients communicate with the DHCP server using multicast addresses within the local link range to obtain IP addresses, or other network configuration parameters. If the server and clients are not in the same link range, the DHCP relay agent is needed for forwarding packets. In this way, the DHCP server is not required for every link range, which reduces costs and facilitates centralized management. DHCP server: A device that allocates IP addresses and other network configuration parameters to DHCP clients.
11.4 DHCP Proxy

DHCP proxy is a mechanism in which the MA5600T/MA5603T acts as a proxy for processing the DHCP packets exchanged between a DHCP server and a DHCP client. That is, the MA5600T/MA5603T modifies the DHCP packets based on the requirements.
11.4.1 Introduction
Definition
DHCP proxy is a mechanism in which the MA5600T/MA5603T acts as a proxy for processing the DHCP packets exchanged between a DHCP server and a DHCP client. That is, the MA5600T/MA5603T modifies the DHCP packets based on the requirements. The DHCP proxy functions are the server ID proxy and the lease time proxy. l Server ID proxy Option 54 in a DHCP packet is called a server identifier (Server ID). The value of the option 54 Server ID is the IP address of a DHCP server and is used to identify the DHCP server. The server ID proxy is a function for modifying option 54 in a DHCP packet so that the IP address of the DHCP server is unavailable to the client. This prevents the attacks initiated by the DHCP client to the DHCP server. l Lease time proxy The lease time of an IP address that a DHCP client applies for is related to options 51, 58, and 59 in a DHCP packet. The lease time proxy is a function for modifying these options in a DHCP packet so that a lease time is available to a client. This lease time is shorter than that directly allocated by the DHCP server, which facilitates the lease time management.
Purpose
Based on different proxy functions, the DHCP proxy addresses different requirements: l Server ID proxy The IP address of the DHCP server can be screened to prevent a DHCP client from attacking the DHCP server. l Lease time proxy The lease time for an IP address available to a DHCP client is long (which is often the case). Therefore, in such a long lease time, the MA5600T/MA5603T is incapable of quickly perceiving whether a user is online. This obstructs the service provisioning.
11 Layer 3 Features
The lease time proxy, however, enables a DHCP client to obtain a shorter lease time for an IP address. The MA5600T/MA5603T with the DHCP proxy function enabled is capable of quickly perceiving whether a user is online or not. Meanwhile, the request packets from the DHCP client for re-leasing an IP address during a short lease time are processed by the MA5600T/ MA5603T and are no longer forwarded to the DHCP server. This decreases the load of the DHCP server in frequently processing the request packets when the short lease time expires.
The MA5600T/MA5603T supports the following DHCP proxy specifications: l l l The MA5600T/MA5603T supports up to 4K DHCP clients. The MA5600T/MA5603T supports globally enabling or disabling the DHCP proxy function. The user port and the subtending port support the DHCP proxy function.

The following lists the reference documents of DHCP proxy: l dsl2006[1].127.00: Proposals of DHCP relay improvements
11.4.4 Availability
Version Support
Feature Dependency
The MA5600T/MA5603T DHCP proxy has the following limitations: l When a common security feature is enabled, the MA5600T/MA5603T supports up to 8K DHCP clients. When the DHCP proxy function is enabled, the MA5600T/MA5603T supports only 4K DHCP clients. When the Layer 3 DHCP relay function is enabled, the MA5600T/MA5603T supports the DHCP proxy. When only the Layer 2 DHCP relay function is enabled, the MA5600T/ MA5603T does not support the DHCP proxy.
11.4.5 Principle
The MA5600T/MA5603T supports the DHCP proxy only when the Layer 3 DHCP relay function is enabled. Both the user port and the subtending port support the DHCP proxy. Figure 11-3 shows an application scenario of the DHCP proxy.
11 Layer 3 Features
Figure 11-3 Application scenario of the DHCP proxy
DHCP server
L3 DHCP relay and DHCP proxy are enabled
Router
MA5600T/ MA5603T
L2 LAN switch
DHCP client
DHCP client
Server ID Proxy
The MA5600T/MA5603T with the DHCP proxy function enabled can monitor all the DHCP packets exchanged between a DHCP client and a DHCP server. After the DHCP proxy function is enabled on the MA5600T/MA5603T, the exchange of packets (in the case of the server ID proxy) between the DHCP server and the DHCP client is as shown in Figure 11-4. l In the downstream direction, the MA5600T/MA5603T modifies the value of option 54 in the response packets (including Offer and ACK) sent by the DHCP server to its own IP address. After the DHCP client receives the packets, option 54 in these packets is the IP address of the MA5600T/MA5603T, and the related field in the DHCP packets is always the IP address of the MA5600T/MA5603T hereafter. In the upstream direction, the MA5600T/MA5603T recovers the value of option 54 in the DHCP packets sent from the DHCP client to the IP address of the actual DHCP server.
Issue 01 (2011-10-30)
252
11 Layer 3 Features
Figure 11-4 Exchange of packets between a DHCP server and a DHCP client (server ID proxy)
DHCP client Discover Offer(Server ID=Proxy IP) Stage of applying for an IP address Request(Server ID=Proxy IP) ACK(Server ID=Proxy IP) DHCP proxy Discover Offer(Server ID=Server IP) Request(Server ID=Server IP) ACK(Server ID=Server IP) DHCP server
Message(Server ID=Proxy IP) Other stages with unicast DHCP packets (re-leasing, releasing) Message(Server ID=Proxy IP)
Message(Server ID=Server IP) Message(Server ID=Server IP)
Lease Time Proxy

The MA5600T/MA5603T with the DHCP proxy function enabled can monitor all the DHCP packets exchanged between a DHCP client and a DHCP server. After the DHCP proxy function is enabled on the MA5600T/MA5603T, the exchange of packets (in the case of the lease time proxy) between the DHCP server and the DHCP client is as shown in Figure 11-5. At the stage of applying for an IP address: 1. The DHCP client sends a packet to the DHCP server for requesting the IP address. The DHCP server then sends a response packet and allocates an IP address whose lease time is L1 to the DHCP client. The MA5600T/MA5603T captures the response packet from the DHCP server, modifies the value of L1 in the packet to a shorter lease time (L2) (which is configurable on the MA5600T/MA5603T), and then sends the Offer (Layer 2) packet to the DHCP client. In this way, the lease time for the IP address allocated to the DHCP client is Layer 2.
2.
At the stage of re-leasing an IP address: 1. 2. When the lease time (L2) expires, to re-lease the IP address, the DHCP client sends a request packet to the DHCP server. The MA5600T/MA5603T captures the request packet and determines whether to send the request packet to the DHCP server based on L1. (1) If it is unnecessary to send the request packet to the DHCP server, the MA5600T/ MA5603T directly responds to the request packet and allows the DHCP client to release the IP address. (2) If it is necessary to send the request packet to the DHCP server, the MA5600T/ MA5603T forwards the request packet sent by the DHCP client to the DHCP server.
11 Layer 3 Features
3. 4.
After receiving the request packet, the DHCP server sends the response packet if it approves to re-lease the IP address to the DHCP client. The MA5600T/MA5603T forwards the response packet sent by the DHCP client to the DHCP server. Thus, the DHCP client is allowed to re-lease the IP address. If a DHCP client sends a request for releasing the IP address, the MA5600T/MA5603T forwards the request to the DHCP server. If the MA5600T/MA5603T detects that the lease time (L2) of the DHCP client expires, but fails to receive any request for re-leasing the IP address from the DHCP client, the MA5600T/MA5603T directly sends a request to the DHCP server for releasing the IP address.
At the stage of releasing an IP address: l l
Figure 11-5 Exchange of packets between a DHCP server and a DHCP client (lease time proxy)
DHCP client Discover Stage of applying for an IP address L1=Lease time allocated by the DHCP server L2=Lease time configured by the DHCP proxy L2<<L1 Offer(L2) Request ACK(L2) DHCP proxy Discover Offer(L1) Request ACK(L1) DHCP server
Request ACK Request ACK Stage of re-leasing an IP address (Based on lease time L2) Request ACK Request ACK
Stage of re-leasing an IP address (Based on lease time L1)
Request ACK
Request ACK
Stage of releasing an IP address (The DHCP client requests for releasing the IP address) Stage of releasing an IP address (The DHCP proxy requests for leasing the IP address after L2 expires.)
Release
Release
Release
Issue 01 (2011-10-30)
254
11 Layer 3 Features
11.5 IP-aware Bridge

11.5.1 Introduction
Definition
IP-aware bridge is a feature in which an access node can implement Layer 3 forwarding without being configured with an IP address.
Purpose
l l l l To implement Layer 3 forwarding. In this feature, a large number of user MAC addresses can be replaced with the system MAC address of a device for packet forwarding. To identify the destination IP address (IP-aware) of users' traffic streams, and send the traffic streams to the corresponding next hop (traffic split) according to route information. To terminate user-side ARP requests, terminate network-side ARP requests, and respond by using ARP proxy. To implement ARP proxy between users so that users who are in the same VLAN and isolated at Layer 2 can interoperate at Layer 3.
Benefits to Users
Layer 3 forwarding can be implemented without occupying IP addresses or requiring the configuration of IP addresses.
l l l l l l SCUN control board: Maximum number of VLANs supporting IP-aware bridge is 64. SCUB control board: Maximum number of VLANs supporting IP-aware bridge is 16. SCUF control board: Maximum number of VLANs supporting IP-aware bridge is 16. Maximum number of virtual IP addresses supported by each VLAN: 8 Interval supported for periodically sending ARP packets: 5-3600s (180s by default) Maximum number of static routes for IP-aware bridge: limited by the system route specification
11.5.3 Availability
License Support
The IP-aware bridge feature is a basic feature of the MA5600T/MA5603T. Therefore, the corresponding service is provided without a license.
Issue 01 (2011-10-30)
255
11 Layer 3 Features
Version Support
Table 11-5 Version support Product MA5600T/ MA5603T Version V800R007C01 and later versions
Limitations
l l l l l l l The IP-aware bridge feature is applicable only to IPoE encapsulation. The IP-aware bridge feature is applicable only to the VLAN with single tag and is not applicable to QinQ VLAN or stacking VLAN. The IP-aware bridge feature is applicable only to the DHCP mode (dynamic IP users). The IP-aware bridge feature does not support dynamic routing protocols (RIP, BGP, OSPF, and IS-IS) or upper-layer protocols such as PIM and NTP. The IP-aware bridge feature is not applicable to the subtending scenario. ARP interoperation is applicable only to users in the same VLAN and is not applicable to super VLAN. ARP interoperation is applicable only to users of the same access node and is not applicable to users of different devices.
11.5.4 Principle
Figure 11-6 shows the application scenario of IP-aware bridge. Figure 11-6 Application scenario of IP-aware bridge
Issue 01 (2011-10-30)
256
11 Layer 3 Features
The DSLAM must meet the following requirements: l l l Converts the user MAC address sent by the CPE into the system MAC address. Sends the traffic streams of users to different ISPs according to the destination IP addresses. Terminates ARP requests: Terminates the ARP requests of users and responds using the system MAC address. Terminates the ARP requests of upper-layer devices to users and responds using the system MAC address. l Does not need an equipment IP address of its own. The DSLAM can query the IP address through the CPE.
Principle Description
Figure 11-7 shows the flow of Layer 3 forwarding of IP-aware bridge in the upstream direction, and Figure 11-8 shows that in the downstream direction.
Issue 01 (2011-10-30)
257
11 Layer 3 Features
Figure 11-7 Flow of Layer 3 forwarding in the upstream direction
Issue 01 (2011-10-30)
258
11 Layer 3 Features
Figure 11-8 Flow of Layer 3 forwarding in the downstream direction
Key Points of the Feature

VLAN-based IP-aware bridge l l l l VLAN-based IP-aware bridge is similar to Layer 3 forwarding but does not occupy IP addresses. The access node has the interface MAC address (system MAC address). The access node supports static routes but does not support dynamic routing protocols. The VLAN can be associated with the VRF (VPN instance). The routing entry and IP address take effect within a VRF.
Issue 01 (2011-10-30)
11 Layer 3 Features
DHCP snooping l l The access node performs DHCP Layer 2 relay to monitor the IP address application process of users and record the IP address information about users. User-side ARP entries are generated according to the DHCP snooping results.
Sending the source IP address of ARP requests to the network side There are two modes. l The first mode: sending ARP requests by using a user IP address (default mode)
NOTE
ARP requests are not sent to the next hop when a valid user IP address does not exist. After a user goes offline (the IP address is released), the user IP address will not be used. Instead, another valid user IP address will be used.
The second mode: sending ARP requests by using a virtual IP address or all-zero IP address (optional mode) When the user RG and the access node next hop do not belong to the same subnet, some network equipment does not respond to ARP requests. In this case, ARP requests need to be sent using a virtual IP address or all-zero IP address as the source IP address. Each VLAN enabled with IP-aware bridge can be configured with eight virtual IP addresses (corresponding to eight subnets). When a corresponding virtual IP address is not available, 0.0.0.0 is used as the source IP address (this method is also called dummy ARP).
Proxy response to user-side and network-side ARP requests l For user-side ARP requests (destination IP address is the user gateway, that is, the networkside equipment of the access node, such as the BRAS) The access node terminates user-side ARP requests and responds by using its own MAC address (system MAC address). l For network-side ARP requests (destination IP address is the user IP address) The access node terminates network-side ARP requests and responds by using its own MAC address (system MAC address). User-side ARP interoperation l l By default, the users in the same VLAN do not interoperate with each other. After global ARP proxy is enabled, users can interoperate at Layer 3.
11.6 VRRP Snooping

VRRP is a fault-tolerant protocol. It allows multiple routers to form a virtual routing device, and provides a mechanism, which ensures that services will be taken over in time by another device once the next hop of a host fails. In this way the continuity and reliability of communication are ensured. VRRP snooping is to snoop (or listen for) VRRP packets.
11.6.1 Introduction
Definition
Virtual Router Redundancy Protocol (VRRP) is a fault-tolerant protocol. It allows multiple routers to form a virtual routing device, and provides a mechanism, which ensures that services
11 Layer 3 Features
will be taken over in time by another device once the next hop of a host fails. In this way the continuity and reliability of communication are ensured. VRRP snooping is to snoop (or listen for) VRRP packets. According to VRRP packets the listening device can confirm the port to which the upstream master router is connected. Then, the listening device will transmit the unicast service stream to the master router and at the same time transparently transmit the VRRP packets of any of other routers to another router in the same VRRP group.
Purpose
To enhance system reliability, the MA5600T/MA5603T is directly dual-homed to two or more BRASs in the upstream direction, and the BRASs run the VRRP protocol. When the MA5600T/ MA5603T works in the SVLAN+CVLAN forwarding mode and MAC address learning is disabled, the upstream ports of the MA5600T/MA5603T need to be isolated from each other in order to prevent unknown unicast broadcast storm. However, when the upstream ports are isolated, the upstream BRASs cannot interoperate VRRP packets. VRRP snooping is adopted for forwarding VRRP packets because VRRP snooping enables the BRASs to interoperate VRRP packets so that the BRASs can run VRRP normally. To prevent asynchronous VRRP status, Huawei develops the VRRP Group Management Protocol (VGMP), which is extended based on VRRP. VGMP manages the VRRP status of each backup group in a unified manner. VGMP provides a mechanism for managing the status synchronization, preemption, and channels of multiple VRRP backup groups. When the MA5600T/MA5603T works in the SVLAN+CVLAN mode, the VGMP protocol may fail to run if the upstream ports are isolated. To enable the BRASs to interoperate VGMP packets, the MA5600T/MA5603T can transparently transmit VGMP packets.
The specifications of the VRRP snooping feature are as follows: l l l l l l Listens for up to 16 virtual router instances. Listens for up to 4 upstream ports. Processes 100 VRRP protocol packets per second. Collects, queries, and deletes the statistics of VRRP packets. Supports configuration of listening ports on the ports on the control board and GIU boards. Transparently transmits all VGMP packets.

The reference standards and protocols of this feature are as follows: l l RFC3768, Virtual Router Redundancy Protocol (VRRP) RFC2787, Definitions of Managed Objects for the Virtual Router Redundancy Protocol
11.6.4 Availability
License Support
This feature is provided without a license.
11 Layer 3 Features
Version Support
Table 11-6 lists the versions that support VRRP snooping. Table 11-6 Base version supporting VRRP snooping Product MA5600T/MA5603T Version V800R008
Hardware Support
Control boards supporting VRRP snooping: SCUN and SCUL. Upstream ports supporting VRRP snooping: ports the GIU boards and the SCUN control board.
Limitations
l The MA5600T/MA5603T must be directly connected to the BRAS, and no devices can be connected in between. The listening port must not be an aggregated port, a port for protection switching, or an MSTP port. This feature requires the upstream router to be configured with the VRRP protocol and to receive and transmit packets as specified by the protocol. When the upstream ports in the SVLAN+CVLAN forwarding mode are isolated, the two upstream routers are interoperating only the VRRP or the VGMP protocol.
l l
11.6.5 Principle
Basic Principle of VRRP Snooping
In a network, the failure of a single router may cause failure of the entire network. To address this problem, multiple VRRP-running routers on the upper layer of the MA5600T/MA5603T can form a set of virtual routers. Thus, another router will automatically take over the forwarding service if the master router fails. Viewed from the MA5600T/MA5603T there is still only one router, but this router may be interconnected to two upstream ports of the MA5600T/ MA5603T. When the path switches from one port to the other, the upstream router will send free ARP packets to update the forwarding path.
Issue 01 (2011-10-30)
262
11 Layer 3 Features
Figure 11-9 Network topology of VRRP snooping
As shown in Figure 11-9, to solve the problem of MAC address insufficiency, the MA5600T/ MA5603T adopts the SVLAN+CVLAN forwarding mode. In this forwarding mode, MAC address learning needs to be disabled, and the upstream ports of the MA5600T/MA5603T need to be isolated to avoid broadcast storm of unknown unicast packets. After the upstream ports of the MA5600T/MA5603T are isolated, the multiple upstream routers directly connected to the MA5600T/MA5603T cannot forward VRRP packets to each other through the upstream port of the MA5600T/MA5603T. The result will be that the routers fail to run the VRRP protocol. To address this problem, the MA5600T/MA5603T needs to employ software forwarding in order to implement VRRP protocol packet exchange between the isolated ports. When MAC address learning is disabled, packets going upstream may be forwarded to the two upstream ports at the same time, which is a waste of bandwidth. In this case, a static MAC address needs to be configured so that unicast packets are forwarded to the master router only. The MA5600T/MA5603T listens to VRRP packets and free ARP packets to learn the upstream port to which the master router is currently connected. By using the static MAC address, the MA5600T/MA5603T forwards Layer 2 service data to this upstream port. When the router sends free ARP packets to the MA5600T/MA5603T for switching the forwarding path, the free ARP packets may be lost due to network reasons. If ARP packets are lost, the MA5600T/MA5603T listens to VRRP packets to update the ARP entry. This prevents a condition where Layer 3 forwarding services are interrupted for a long time because the forwarding path is not updated in time.
VRRP Snooping in the VLAN+MAC Forwarding Mode

In the VLAN+MAC forwarding mode, the two routers to which the MA5600T/MA5603T is dual-homed can run the VRRP protocol without additional processing on the MA5600T/ MA5603T as long as the following condition is met: The two upstream ports connected to the two routers can interoperate, which allows for normal forwarding of VRRP packets between the two routers. When the network condition is good, or when the MA5600T/MA5603T needs not consider the loss of free ARP packets (a router may provide for retransmission of free ARP packets), VRRP snooping needs not be enabled on the MA5600T/MA5603T when the MA5600T/MA5603T runs in the VLAN+MAC forwarding mode.
11 Layer 3 Features

Glossary
Table 11-7 Glossary of VRRP snooping Term VRRP router Virtual router Virtual IP address IP address owner Explanation A router that runs the VRRP protocol. This router may belong to one or more virtual routers. An abstract device managed through VRRP, also called a VRRP backup group. It is used as the default gateway of the hosts in a shared LAN. A virtual router carries a virtual router ID and a set of virtual IP addresses. The IP address of a virtual router. A virtual router may have one or more IP addresses, which are configured by the operator. A VRRP router is regarded as an IP address owner if this router uses the IP address of the virtual router as a real interface address. When working in the normal state, the IP address owner responds to packets addressed to the virtual IP address for ICMP pings and TCP connections. A MAC address generated by the virtual router according to the virtual router ID. A virtual router has one virtual MAC address in the format of 00-00-5E-00-01-{VRID}. A virtual router responds to ARP requests using the virtual MAC address instead of the real MAC address of the interface. An IP address selected from the real interface IP addresses. The first configured IP address is usually selected. VRRP advertisements are sent using the primary IP address as the source address of the IP packet. The VRRP router that assumes the responsibility of forwarding packets or responding to ARP requests. All the packets forwarded by the master router are sent to the virtual IP address. If the IP address owner is available, it always becomes the master router. A set of VRRP routers ready to assume the forwarding responsibility if the master router fails. A mode in which a backup router with a higher priority than the current master router voluntarily becomes a master router.
Virtual MAC address Primary IP address Master router
Backup router Preemption mode

Table 11-8 Acronyms and abbreviations of VRRP snooping Acronym/ Abbreviati on VRRP
Issue 01 (2011-10-30)
Full Spelling
Virtual Router Redundancy Protocol

11 Layer 3 Features
Acronym/ Abbreviati on VGMP
Full Spelling
VRRP Group Management Protocol
11.7 Routing
Routing is a common term used for describing the path through which the packets from a host in a network travel to a host in another network.
11.7.1 Introduction
Definition
Routing is a common term used for describing the path through which the packets from a host in a network travel to a host in another network. Routers send packets on the Internet. A router selects a suitable path in a network according to the destination address included in a received packet, and sends the packet to the next router on the path. In this way, the packet travels over the Internet Until it reaches the destination host.
Purpose
The access equipment, serving as a basic element in the entire telecom network, must support the functions of remote operation, management and maintenance on the equipment itself. With the development of small-size access equipment that can be managed remotely, the access equipment needs to feature the functions of a BRAS, such as allocation of network addresses and user management. In this way, the access equipment must support the routing feature. A MA5600T/MA5603T can also serve as a router.

The following lists the reference documents of routing: l l l l l RFC 2453, Routing Information Protocol RFC 2328, Open Shortest Path First RFC 3784, IS-IS extensions for Traffic Engineering RFC 1771, A Border Gateway Protocol 4 (BGP-4) IETF RFC 2764: A Framework for IP Based Virtual Private Networks
11.7.3 Availability
Hardware support
No additional hardware is required for supporting the routing feature.
11 Layer 3 Features
License support
The dynamic routing function of the MA5600T/MA5603T is under license. Therefore, the license is required for accessing the corresponding service.
VRF Limitation
l l Any two VRFs cannot communicate with each other. The Layer 3 features such as AAA, RADIUS, voice features, MPLS, multicast, NTP, and ACL do not support configuring VRF.
The MA5600T/MA5603T supports both static routes and dynamic routes. The dynamic routing protocols supported are as follows: l MA5600T Static RIP OSPF Default IS-IS BGP Equal and Weighted Cost Multi-Path (ECMP) l MA5603T Static RIP OSPF Default
11.7.5 Principle
Working Principle of Routers
The router logically takes the path through which a packet travels from the network ingress to the network egress as a route unit; this is called a hop. The path that a hop covers is called a route segment. As shown in Figure 11-10, the packets from Host PC_A travel through three networks and two routers until they reach Host PC_C and the hop count is three. If one node is connected to another through a network, the two nodes are adjacent on the Internet. Similarly, adjacent routers mean that these routers are connected to the same network. The hop count from a router in a network to a host in the same network is zero. Figure 11-10 shows the working principle of routers.
Issue 01 (2011-10-30)
266
11 Layer 3 Features
Figure 11-10 Working principle of routers

Router Router Route segment Router Router Router PC_C PC_B
PC_A
Routing Table
Each router maintains a routing table. The routing table is key for forwarding packets. The route entries in the table are used for the following: l l Through which physical interface of the router a packet can be forwarded to a specific subnet or host so as to reach the next router along the path. Whether the packet can be sent to the destination host in an interconnected network without passing through other routers.
The routing table contains the following key entries: l Destination address The destination address is a 32-bit character that labels the destination IP address or destination network of an IP packet. l Subnet mask The subnet mask consists of a sequence of "1"s, and can be expressed in dotted decimal format or as the total number of consecutive "1"s. The mask is used with the destination address to identify the subnet address of the destination host or router. To obtain the subnet address of the destination host or router, perform an AND operation for the destination address and the subnet mask. For example, if a router' s destination address and subnet mask are 129.102.8.10 and 255.255.0.0, respectively, the router' s subnet address is 129.102.0.0. l l l Output interface The output interface specifies the interface of a router for IP packet forwarding. Next hop IP address The next hop IP address indicates the next router through which an IP packet will pass. Route priority The route with the highest priority (smallest value) will be the optimal one. You can configure multiple routes with different priorities to the same destination, but only one route is selected based on the priority for IP packet forwarding.
11 Layer 3 Features
cost: Indicates the cost of reaching the destination.
Route Classification
Based on the destination, routes can be classified as: l l Subnet route: Its destination is a subnet. Host route: Its destination is a host.
Based on the connection between the destination and the router, routes can be classified as: l l Direct route: Its destination network is directly connected to the router. Indirect route: Its destination network is not directly connected to the router.
To avoid large routing tables, a default route can be assigned. Once a packet fails to find a dedicated route in the routing table, the default route is selected for forwarding the packet. Figure 11-11 and Table 11-9 shows some interconnected networks. The digits in each network represent the IP address of the network. Router 8 is connected to three networks. Therefore, it has three IP addresses and three physical ports. Figure 11-11 Interconnected networks
16.0.0.1 15.0.0.2 16.0.0.0 16.0.0.3
R6
16.0.0.2
R7
10.0.0.2
15.0.0.0 15.0.0.1 13.0.0.2
R5
13.0.0.3
10.0.0.0
2 3 R8 13.0.0.0 R2 1 11.0.0.1 14.0.0.2 13.0.0.4 13.0.0.1 11.0.0.0 14.0.0.0 R3 10.0.0.1
14.0.0.1
R1
12.0.0.2 12.0.0.0
R4
11.0.0.2 12.0.0.1
12.0.0.3
Table 11-9 Routing table of Router 8 Subnet of the Destination Host 10.0.0.0 11.0.0.0 12.0.0.0 13.0.0.0 14.0.0.0
Issue 01 (2011-10-30)
Forward or Forward from... Directly Directly 11.0.0.2 Directly 13.0.0.2
Through Port... 2 1 1 3 3
268
11 Layer 3 Features
Subnet of the Destination Host 15.0.0.0 16.0.0.0
Forward or Forward from... 10.0.0.2 10.0.0.2
Through Port... 2 2
Routing Management Policy

The MA5600T/MA5603T supports the configuration of static routes and the dynamic routing protocols such as RIP, OSPF and BGP/IS-IS. The MA5600T/MA5603T manages the static and dynamic routes in a unified manner. The static routes and the routes discovered by the routing protocols such as RIP and OSPF can be shared.
Routing Protocols and Routing Priority

The current route to a specific destination at a specific moment can only be determined by one routing protocol. Each routing protocol (including the static routing protocol) is allocated a priority. When multiple route sources exist, the route discovered by the routing protocol with the highest priority becomes the current route. Table 11-10 lists various routing protocols and the default priorities of the routes discovered by them. Table 11-10 Routing protocols and their default routing priorities Routing Protocol DIRECT OSPF INTERNAL EIGRP STATIC RIP OSPF ASE EXTERNAL EIGRP IBGP EBGP UNKNOWN Routing Priority 0 10 50 60 100 150 160 256 256 255
The smaller the value, the higher the priority. In this table, "0" indicates the direct route, and "255" indicates any route from an untrusted source. You can define the priorities for all dynamic routing protocols except the direct route (DIRECT) and the BGP (IBGP, EBGP). In addition, the priorities of any two static routes can be different.
11 Layer 3 Features
Route Sharing
Different routing protocols can find different routes as they use different algorithms. Therefore, a problem arises, that is, how to share the routes discovered by various routing protocols. A routing protocol might need to import routes discovered by other protocols to diversify its own routes. However, a protocol only needs to import qualified routes by setting attributes of the routes to be imported. To realize a route policy, you must define the attributes of the routes to which the route policy is to be applied, such as the destination address, and the address of the router distributing routes. You can define the matching rules in advance so that they can be applied in a route policy for route distribution, reception and importing. The MA5600T/MA5603T supports importing the routes discovered by one protocol to another protocol. Each protocol has its own route importing mechanism.
Filters
The following describes the several filters used by the MA5600T/MA5603T. l ACL An ACL is defined with a specified IP address and subnet range for identifying routes with the desired destination segment address or next hop address. l Address prefix list An address prefix list is similar to an ACL in functions, but is more flexible and comprehensible. When applied to filter routes, the address prefix list targets at the destination address fields. Identified by name, an address prefix list contains multiple entries. Each entry specifies a matching range and is identified with index-number. Index-number also specifies the matching order. In the process of matching, the router checks every entry identified with index-number in the ascending order. If the route matches one entry, it means that the route matches the address prefix list, and comparison with next entry is unnecessary. l Route policy Route policy is a sophisticated filter to identify routes with the desired attributes and modify some attributes if conditions are satisfied. Route policy can define its own match rules using other filters. A route policy consists of several nodes (matching units). The node number is also the matching order. Every node consists of if-match clause and apply clause. if-match clause defines the matching order. The objects of the matching are some attributes of the routes. The relationship between two if-match clauses of a node is "and." The match test can be considered as pass-through only when all if-match clauses of a node are satisfied. Apply clause specifies the action to be taken when node match test is conducted, that is, set some attributes of the routes. The relationship between nodes of a route policy is "or." The system checks every node of a route policy. If one node passes the match test, it means that the route policy passes the match test, and match test for next node is not required.
11 Layer 3 Features
Applications of the Routing Policy

The two applications of the routing policy are as follows: l l When importing routes discovered by other protocols, a routing protocol can apply this filter to obtain the required routes. When transmitting or receiving routes, a routing protocol can apply the filter so that only the required routes are transmitted or received.
11.7.6 Static Route

11.7.6.1 Introduction to Static Routes Definition
Static routes need to be manually configured by the administrator.
Purpose
On a simple network, the administrator just needs to configure static routes so that the network can run properly. Properly configuring and using static routes can improve network performance and guarantee the required bandwidth for important applications. When a network fault occurs or the network topology changes, however, static routes cannot automatically change and must be changed manually by the administrator.
11.7.6.2 Specifications
l IPV4: When using SCUN, the MA5600T/MA5603T supports up to 5120 routes, including 4096 static routes (max). When using SCUL, the MA5600T/MA5603T supports up to 1024 routes, including 1000 static routes (max). When using SCUB, the MA5600T/MA5603T supports up to 5120 routes, including 4096 static routes (max). When using SCUF, the MA5600T/MA5603T supports up to 5120 routes, including 4096 static routes (max).
11.7.6.3 References
None.
11.7.6.4 Components of Static Routes

On the MA5600T/MA5603T, you can run the ip route-static command to configure a static route, which consists of the following: l l
Issue 01 (2011-10-30)
Destination Address and Mask Outbound Interface and Next-Hop Address

11 Layer 3 Features
Destination Address and Mask

In the ip route-static command, the IPv4 address is expressed in dotted decimal notation, and the mask is expressed in dotted decimal notation or represented by the mask length (the number of consecutive 1s in the mask).
Outbound Interface and Next-Hop Address

When configuring a static route, you can specify an outbound interface, a next-hop address, or both the outbound interface and the next hop-address as required. Actually, each routing entry requires a next-hop address. Before sending a packet, a device needs to search its routing table for the route matching the destination address in the packet by using the longest match rule. The device can find the associated link layer address to forward the packet only after the next-hop address of the packet is specified.
11.7.6.5 Applications of Static Routes

As shown in Figure 11-12, the network topology is simple, and network communication can be implemented through static routes. It is required to specify an address for each physical network, identify indirectly-connected physical networks for each Router, and configure static routes for the indirectly-connected physical networks. Figure 11-12 Networking diagram of static routes
2 1 RouterA
RouterB
4 5 RouterC
In Figure 11-12, static routes to networks 3, 4, and 5 need to be configured on Router A; static routes to networks 1 and 5 need to be configured on Router B; static routes to networks 1, 2, and 3 need to be configured on Router C.
Default Static Route

When the ip route-static command is run to configure a static route, if the destination address and the mask are set to all 0s (0.0.0.0 0.0.0.0), it indicates that a default route is configured. This simplifies the network configuration. In Figure 11-12, because the next hop of the packets sent by Router A to networks 3, 4, and 5 is Router B, a default route can be configured on Router A to replace the three static routes destined for networks 3, 4, and 5 in the preceding example. Similarly, only a default route from Router C to Router B needs to be configured to replace the three static routes destined for networks 1, 2, and 3 in the preceding example.
11 Layer 3 Features
Floating Static Routes

Different static routes can be configured with different preferences so that routing management policies can be flexibly applied. Specifying different preferences for multiple routes to the same destination can implement route backup. As shown in Figure 11-13, there are two static routes from Router A to Router C. Normally, in the routing table, only the static route with the next hop being Router B is in the Active state because this route has a higher preference. The other static route with the next hop being Router D functions as a backup route. The backup route is activated to forward data only when the primary link becomes faulty. After the primary link recovers, the static route with the next hop being Router B becomes active to forward data. Therefore, the backup route is also called a floating static route. The floating static route becomes ineffective when a fault occurs on the link between Router B and Router C. Figure 11-13 Networking diagram of a floating static route
RouterB
Preference=60 Preference=100
RouterA
RouterC
RouterD
Load Balancing Among Static Routes

Specifying the same preference for multiple routes to the same destination can implement load balancing. As shown in Figure 11-14, there are two static routes with the same preference from Router A to Router C. The two routes exist in the routing table and forward data at the same time. Figure 11-14 Load balancing among static routes RouterB
Preference=60 Preference=60 RouterC
RouterA
RouterD
11 Layer 3 Features
11.7.6.6 BFD for Static Routes

Different from dynamic routing protocols, static routes do not have a detection mechanism. As a result, when a fault occurs on the network, the administrator needs to handle it. Bidirectional Forwarding Detection (BFD) for static route is introduced to bind a static route to a BFD session so that the BFD session can detect the status of the link where the static route resides. After BFD for static route is configured, each static route can be bound to a BFD session. l If the BFD session on the link of a static route detects that the link changes from Up to Down, BFD reports it to the system. Then, the system deletes the route from the IP routing table. When a BFD session is established on the link of a static route or the BFD session changes from Down to Up, BFD reports it to the system. Then, the system adds the route to the IP routing table.
BFD for static route has one mode: l Single-hop detection For a non-iterated static route, the configured outbound interface and next-hop address are the information about the directly connected next hop. In this case, the outbound interface bound to the BFD session is the outbound interface of the static route, and the peer address is the next-hop address of the static route.
NOTE
If the next hop of a route is not directly reachable, the route cannot be used for packet forwarding. Based on information about the current next hop of this route, the system will calculate an actual outbound interface and an actual next hop. This process is called route iteration. In the display ip routing-table command output, if the Flags value of a route is displayed R, the route is an iterated route. Otherwise, the route is not an iterated route.
NOTE
Only IPv4 supports BFD for static routing.
11.7.6.7 Terms and Abbreviations Terms

None.
Abbreviations
Abbreviatio n BFD Full Spelling Bidirectional Forwarding Detection
Issue 01 (2011-10-30)
274
11 Layer 3 Features
11.7.7 RIP
RIP is a dynamic routing protocol based on the V-D algorithm. Based on RIP, the routing information is exchanged through UDP data packets. This topic provides introduction to this feature and describes the principle of this feature.
11.7.7.1 Introduction to RIP Definition

RIP is short for Routing Information Protocol. RIP is a simple Interior Gateway Protocol, mainly used in small-scale and simply-structured networks such as campus networks and regional networks. RIP is not suitable for complex environments or large-scale networks. RIP is based on the Distance-Vector (DV) algorithm. It exchanges routing information through User Datagram Protocol (UDP) packets. The port number used by RIP is 520. RIP employs Hop Count (HC) to measure the distance to the destination. The distance is called the metric value. In RIP, the default HC from a router to its directly connected network is 0,and the HC from a router to a network that is reachable through another router is 1, and so on. That is to say, the HC equals the number of routers passed from the local network to the destination network. To speed up the convergence, RIP defines the HC as an integer that ranges from 0 to 15. The HC equal to or greater than 16 is defined as infinity, that is, the destination network or the host is unreachable. RIP, therefore, is not applied to large-scale networks. To improve the performance and to prevent routing loops, RIP supports split horizon and poison reverse.
Purpose
As an earliest IGP, RIP is used in small-scale networks that support RIP. The implementation of RIP is simple. The configuration and maintenance of RIP are easier than those of the Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS) protocols. RIP is thus widely used.
l l l l When using SCUN, the MA5600T/MA5603T supports up to 5120 RIP routes. When using SCUL, the MA5600T/MA5603T supports up to 1024 RIP routes. When using SCUB, the MA5600T/MA5603T supports up to 5120 RIP routes. The MA5600T/MA5603T is able to exchange RIP route information with the user-side, cascading-side, and network-side devices.
11.7.7.3 References
The following table lists the references of this document. Document RFC1058 Description This document describes RIP protocol, describes the elements, characteristic, limitation of RIP version 1.
Remar ks -
Issue 01 (2011-10-30)
275
11 Layer 3 Features
Document RFC2453
Description This document specifies an extension of the Routing Information Protocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP messages and to add a measure of security.
Remar ks -
11.7.7.4 RIP-1
RIP-1, that is, RIP version 1, is a classful routing protocol. It supports the advertisement of protocol packets only in broadcast mode. Figure 11-15 shows the packet format.A RIP packet can carry a maximum of 25 entries. RIP is based on UDP, and a RIP-1 data packet cannot be longer than 512 bytes. The RIP-1 protocol packet does not carry any mask, so it can identify only the routes of the natural network segment such as Class A, Class B, and Class C. RIP-1, therefore, does not support route aggregation or discontinuous subnet. Figure 11-15 RIP-1 packet format 0 Header 7 Version 15 Must be zero Must be zero 31
Command Address family identifier
Route Entries
IP address Must be zero Must be zero Metric
11.7.7.5 RIP-2
RIP-2, that is, RIP version 2, is a classless routing protocol. Figure 11-16 shows the packet format. Figure 11-16 RIP-2 packet format
0 Header Command
7 Version Address Family Identifier
15 Must be zero Route Tag
31
IP Address Route Entries Subnet Mask Next Hop Metric
Issue 01 (2011-10-30)
276
11 Layer 3 Features
Compared with RIP-1, RIP-2 has the following advantages: l l l l l It supports route tag and can flexibly control routes on the basis of the tag in the routing policy. Its packets contain mask information and support route aggregation and Classless Interdomain Routing (CIDR). It supports the next hop address and can select the optimal next hop address in the broadcast network. It uses multicast routes to send update packets. Only RIP-2 routers can receive protocol packets. This reduces the resource consumption. To enhance the security, RIP-2 provides two authentication modes to enhance security: plain-text authentication and MD5 authentication.
11.7.7.6 Timer
RIP mainly uses three timers: l l l Update timer: The timer triggers the sending of update packets every 30s. Age timer: If a RIP router does not receive any update packet from its neighbors in the aging time, the RIP router considers the route to its neighbors unreachable. Garbage-Collect timer: If the route is no longer valid after the timer times out, the entry is removed from the RIP routing table.
The following describes the relationship among the three timers: The advertisement of RIP routing update is triggered by the update timer every 30 seconds. Each entry is associated with two timers, the age timer and the garbage-collect timer. When a route is learned and added in the routing table, the age timer is initialized. If no Update packet is received from the neighbor for 180 seconds, the metric of the route is set to 16 (specifying the route as unreachable). At the same time, the garbage-collect timer is initialized. If no Update packet is received for 120 seconds, the entry is deleted after the garbage-collect timer times out.
11.7.7.7 Split Horizon

The principle of split horizon is that a route learnt by RIP on an interface is not sent to neighbors from the interface. This reduces bandwidth consumption and avoids route loops. Figure 11-17 Schematic diagram of split horizon
10.0.0.0/2
RouterA RouterB
10.0.0.0/2
As shown in Figure 11-17, Router B sends a route to 10.0.0.0 to Router A and Router A does not send the route back to Router B.
11 Layer 3 Features
11.7.7.8 Poison Reverse

The principle of poison reverse is that RIP sets the cost of the route learnt from an interface of a neighbor to 16 (specifying the route as unreachable) and then sends the route from the interface back to the neighbor. In this way, RIP can delete useless routes from the routing table of the neighbor. Poison reverse of RIP can also avoid route loops. Figure 11-18 Schematic diagram of poison reverse
10.0.0.0/8 RouterA cost=16 cost=1 10.0.0.0/8 RouterB
As shown in Figure 11-18, if poison reverse is not configured, Router B sends Router A a route that is learnt from Router A and the cost of the route from Router A to network 10.0.0.0 is 1. If the route from Router A to network 10.0.0.0 is unreachable and Router B keeps sending Router A routes to network 10.0.0.0 because Router B fail to receive the route update packet from Router A, a route loop forms. If Router A sends Router B a message that the route is unreachable after receiving a route from Router B, Router B no longer learns the reachable route from Router A, thus avoiding route loops. If both poison reverse and split horizon are configured, simple split horizon (the route learnt from an interface is not sent back through the interface) is replaced by poison reverse.
11.7.7.9 Triggered Update

Triggered update occurs when the local routing information changes and the local router immediately notifies its neighbors of the changes of routing information by sending the triggered update packet. Triggered update shortens the network convergence time. When the local routing information changes, the local router immediately notifies its neighbors of the changes of routing information rather than waiting for periodical update.
Issue 01 (2011-10-30)
278
11 Layer 3 Features
Figure 11-19 Schematic diagram of triggered update
The network to 11.4.0.0 fails. 11.1.0.0 E0 S0 RouterA RouterC E0 S0 11.2.0.0 S0 11.3.0.0
The network to 11.4.0.0 fails.
RouterB S1
The network to 11.4.0.0 fails. 11.4.0.0
As shown in Figure 11-19, when network 11.4.0.0 is unreachable, Router C learns the information first. Usually, the route update message is sent to neighbors every 30s. If the update message of Router B is sent to Router C when Router C is waiting for the route update message, Router C learns the faulty route to network 11.4.0.0 from Router B. In this case, the routes from Router B or Router C to network 11.4.0.0 point to Router C or Router B respectively, thus forming a route loop. If Router detects a network fault and immediately sends a route update message to Router B before the new update interval reaches. Consequently, the routing table of Router B is updated in time, and routing loops are avoided. There is another mode of triggering updates: The next hop of the route is unavailable because the link is faulty. The local device needs to notify neighboring device about the unreachability of this route. This is done by setting the cost of the route as 16 and advertising the route. This is also called route-withdrawal.
11.7.7.10 Route Aggregation

When different subnet routes in the same natural network segment are transmitted to other network segments, these routes are aggregated into one route of the same segment. This process is called route aggregation. RIP-1 packets do not carry mask information, so RIP-1 can advertise only the routes with natural masks. RIP-2 packets carry mask information, so RIP-2 supports subnetting. RIP-2 route convergence can improve extensibility and efficiency and minimize the routing table of a large-scale network. Route convergence is classified into two types as follows: l Classful convergence based on RIP processes: Aggregated routes are advertised with natural masks. When split horizon or poison reverse is configured, classful aggregation becomes invalid due to the following reasons: split
11 Layer 3 Features
horizon and poison reverse suppress routes to be advertised and when classful aggregation is configured, an aggregated route may be the aggregation result of routes from different interfaces. As a result, a conflict occurs on the aggregated route in advertisement. For example, router 10.1.1.0 /24 (metric=2) and router 10.1.2.0 /24 (metric=3) are aggregated as an aggregated route (10.0.0.0 /8(metric=2)) in the natural network segment. RIP-2 aggregation is classful, thus obtaining the optimal metric. l Interface-based aggregation: A user can specify an aggregation address. For example, router 10.1.1.0 /24(metric=2) and router 10.1.2.0 /24 (metric=3) are aggregated as an aggregated route (10.1.0.0 /16(metric=2)).
11.7.7.11 Multi-process and Multi-instance

For easy management and effective control, RIP supports multi-process and multi-instance. The multi-process feature allows a set of interfaces to be associated with a specific RIP process. This ensures that the specific RIP process performs all the protocol operations only on this set of interfaces. Thus, multiple RIP processes can work on a single router and each process is responsible for a unique set of interfaces. In addition, the routing data is independent between RIP processes; however, routes can be imported between processes. For the routers that support the VPN, each RIP process is associated with a specific VPN instance. In this case, all the interfaces attached to the RIP process should be associated with the RIPprocess-related VPN instance.
11.7.7.12 Hot Backup

Routers with distributed architecture support the RIP Hot Standby (HSB) feature. RIP backs up data from the Active Main Board (AMB) to the Standby Main Board (SMB). Whenever the AMB fails, the SMB becomes active. In this manner, RIP, being free from active/standby switchover, proceeds to work normally. RIP supports only the backup of RIP configurations. RIP performs Graceful Restart (GR) to resend a routing request to neighbors and synchronize route database.
11.7.7.13 Terms and Abbreviations Term

Term Poison reverse Explanation RIP sets the cost of the route learnt from an interface to 16 (specifying the route as unreachable) and then sends the route from the interface to neighbors. A route learnt by RIP on an interface is not sent to neighbors from the interface.
Split horizon
Issue 01 (2011-10-30)
280
11 Layer 3 Features
Abbreviation
Abbreviation RIP Full Spelling Routing Information Protocol
11.7.8 IS-IS
The Intermediate System-to-Intermediate System (IS-IS) protocol is a dynamic routing protocol initially designed by the International Organization for Standardization (ISO) for its Connectionless Network Protocol (CLNP).
11.7.8.1 Introduction to IS-IS Definition

The Intermediate System-to-Intermediate System (IS-IS) is a dynamic routing protocol initially designed by the International Organization for Standardization (ISO) for its Connectionless Network Protocol (CLNP). To support IP routing, the Internet Engineering Task Force (IETF) extends and modifies IS-IS in RFC 1195. This enables IS-IS to be applied to TCP/IP and OSI environments. This type of IS-IS is called Integrated IS-IS or Dual IS-IS. IS-IS stated in this document refers to Integrated IS-IS, unless otherwise stated.
Purpose
As an Interior Gateway Protocol (IGP), IS-IS is used in Autonomous Systems (ASs). IS-IS is a link state protocol. It uses the Shortest Path First (SPF) algorithm to calculate routes.
l l l l When using SCUN, the MA5600T/MA5603T supports up to 5120 IS-IS routes. When using SCUL, the MA5600T/MA5603T supports up to 1024 IS-IS routes. When using SCUB, the MA5600T/MA5603T supports up to 5120 IS-IS routes. The MA5600T/MA5603T is able to exchange IS-IS route information only with the network-side device.
11.7.8.3 References
Table 11-11 The following table lists the references of this document. Document ISO 10589 ISO 8348/Ad2
Issue 01 (2011-10-30)
Description ISO IS-IS Routing Protocol Network Services Access Points
Remarks 281
11 Layer 3 Features
Document RFC 1195
Description Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
Remarks Multiple authentication passwords are not supported. -
RFC 2763 RFC 2966 RFC 2973 RFC 3277 RFC 3373 RFC 3567
Dynamic Hostname Exchange Mechanism for IS-IS Domain-wide Prefix Distribution with Two-Level IS-IS IS-IS Mesh Groups IS-IS Transient Blackhole Avoidance Three-Way Handshake for IS-IS Pointto-Point Adjacencies Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication Recommendations for Interoperable Networks using IS-IS IS-IS extensions for Traffic Engineering Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit Recommendations for Interoperable IP Networks using IS-IS Restart signaling for IS-IS Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels Management Information Base for ISIS Multi Topology (MT) Routing in IS-IS Routing IPv6 with IS-IS M-IS-IS: Multi Topology (MT) Routing in IS-IS Admin Tag
RFC 3719 RFC 3784 RFC 3786 RFC 3787 RFC 3847 RFC 3906
RFC 4444 RFC 5120 draft-ietf-IS-IS-ipv6-05 draft-ietf-IS-IS-wg-multitopology-11 draft-ietf-isis-admintags-02(Admin Tag)
Issue 01 (2011-10-30)
282
11 Layer 3 Features
11.7.8.4 Basic Concepts of IS-IS Development of IS-IS

CLNP is a Layer 3 protocol in the OSI model posed by the ISO. IS-IS is initially designed by the ISO and is used as a routing protocol based on CLNP addressing. Figure 11-20 OSI model
OSI Reference Model Application Presentation Session Transport Network DataLink Physical
OSI Protocol Suite CMIP ASES ACSE DS ROSE FTAM RTSE MHS CCRSE VTP ......
Presentation Service/Presentation Protocal Session Service/Session Protocal TP0 TP1 TP2 TP3 TP4 CONP/CMNS IS-IS IEEE 802.2 IEEE 802.3 Hardware IEEE 802.3 ES-IS IEEE 802.5 Token Ring FDDI X.25 CLNP/CLNS
Token Ring Hardware
FDDI X.25 Hardware Hardware
OSI adopts systemized (or hierarchical) addressing. The services on the transport layer in OSI can be addressed through the Network Service Access Point (NSAP). The following lists the commonly used terms in OSI: l l l l CLNS: indicates the Connectionless Network Service. CLNP: indicates the Connectionless Network Protocol. CMNS: indicates the Connection-Mode Network Service. CONP: indicates the Connection-Oriented Network Protocol.
OSI implements CLNS through CLNP, and implements CMNS through CONP. CLNS is implemented through the following protocols: l l l CLNP: is similar to the IP protocol in TCP/IP. IS-IS: is the routing protocol of an intermediate system. ES-IS: is the protocol used between a host system and an intermediate system. It is similar to ARP or ICMP in IP.
Issue 01 (2011-10-30)
11 Layer 3 Features
Table 11-12 Concepts in OSI and IP Abbre viation IS ES DIS SysID PDU LSP NSAP Concepts in OSI Intermediate System End System Designated Intermediate System System ID Protocol Data Unit Link state Protocol Data Unit Network Service Access Point Concepts in IP Router Host Designated Router (DR) in OSPF Router ID in OSPF IP packet OSPF LSA IP address
With the popularity of TCP/IP, the IETF extends and modifies IS-IS in RFC 1195 to support IP routing. This enables IS-IS to be applied to TCP/IP and OSI environments. This type of IS-IS is called Integrated IS-IS or Dual IS-IS.
Address Structure of IS-IS

In OSI, the NSAP is an address used to locate resources. The ISO adopts the address structure shown in Figure 11-21, that is, NSAP. NSAP is composed of the Initial Domain Part (IDP) and the Domain Specific Part (DSP). The IDP is equal to the network ID in the IP address, and the DSP is equal to the subnet number and host address in an IP address. As defined by the ISO, the IDP consists of the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI). The AFI specifies the address assignment mechanism and the address format; the IDI identifies a domain. The DSP consists of the High Order DSP (HODSP), system ID, and NSAP Selector (SEL). The HODSP is used to divide areas; the system ID identifies a host; the SEL indicates the service type. The lengths of the IDP and the DSP are variable. The maximum length of the NSAP is 20 bytes and its minimum length is 8 bytes. Figure 11-21 Schematic diagram of the address structure of IS-IS
IDP AFI IDI High Order DSP
DSP System ID SEL(1 octet)
Area Address
Issue 01 (2011-10-30)
284
11 Layer 3 Features
Area address The IDP together with the HODSP of the DSP can identify a routing domain and the areas in a routing domain; therefore, the combination of the IDP and HODSP is referred to as an area address, which is equal to an area number in OSPF. There cannot be the same area address in a routing domain. and the Level-1 area addresses of the routers in the same area must be the same. In general, a router can be configured with only one area address. The area address of all nodes in an area must be the same. In the implementation of device, an IS-IS process can be configured with a maximum of three area addresses for supporting seamless combination, division, and transformation of areas.
System ID A system ID uniquely identifies a host or a router in an area. In the device, the fixed length of the system ID is 48 bits (6 bytes). In actual applications, a router ID corresponds to a system ID. If a router takes the IP address 168.10.1.1 of Loopback 0 as its router ID, its system ID used in IS-IS can be obtained in the following manners: Extend each part of the IP address 168.10.1.1 to 3 bits and add 0 to the front of the part that is shorter than 3 bits. Divide the extended address 168.010.001.001 into three parts, with each part consisting of four decimal digits. The reconstructed 1680.1000.1001 is the system ID. There are many ways to specify a system ID. You need to ensure that the system ID uniquely identifies a host or a router.
SEL The role of an SEL (also referred to as NSAP Selector or N-SEL) is similar to that of the "protocol identifier" of IP. A transport protocol matches an SEL. The SEL is always "00" in IP.
NET A Network Entity Title (NET) indicates the network layer information of an IS itself. It does not contain the transport layer information (SEL = 0). A NET can be regarded as a special NSAP. The length of the NET field is the same as that of an NSAP. Its maximum length is 20 bytes and its minimum length is 8 bytes. When configuring IS-IS on a router, you can configure only a NET instead of an NSAP. In general, an IS-IS process is configured with only one NET. When an area needs to be redefined, such as being combined with other areas or divided into sub-areas, you can configure the router with multiple NETs to ensure the correctness of routes. An IS-IS process can be configured with a maximum of three area addresses, and thus a maximum of three NETs can be configured. When configuring multiple NETs, ensure that their system IDs are the same. For example, there is a NET ab.cdef.1234.5678.9abc.00, in which, the area is ab.cdef, the system ID is 1234.5678.9abc, and the SEL is 00.
NOTE
The routers in an area must have the same area address.
IS-IS PDU Format

The types of PDUs for IS-IS include Hello, LSPs, CSNPs, and PSNPs.
11 Layer 3 Features
Table 11-13 PDU types Type Value 15 16 17 18 20 24 25 26 27 l PDU Type Level-1 LAN IS-IS Hello PDU Level-2 LAN IS-IS Hello PDU Point-to-Point IS-IS Hello PDU Level-1 Link State PDU Level-2 Link State PDU Level-1 Complete Sequence Numbers PDU Level-2 Complete Sequence Numbers PDU Level-1 Partial Sequence Numbers PDU Level-2 Partial Sequence Numbers PDU Name L1 LAN IIH L2 LAN IIH P2P IIH L1 LSP L2 LSP L1 CSNP L2 CSNP L1 PSNP L2 PSNP
Hello packet format Hello packets, also called the IS-to-IS Hello PDUs (IIH), are used to set up and maintain neighbor relationships. Among them, Level-1 LAN IIHs are applied to the Level-1 routers on broadcast LANs; Level-2 LAN IIHs are applied to the Level-2 routers on broadcast LANs; P2P IIHs are applied to non-broadcast networks. Packets in different networks have different formats. Figure 11-22 shows the format of a Hello packet in a broadcast network (the part in blue is the common header). Figure 11-22 Format of a Level-1 or Level-2 LAN IIH
No. of Octets Intradomain Routeing Protocol Discriminator Length Indicator Version/Protocol ID Extension ID Length R R R PDU Type Version Reserved Maximum Area Address Reserved/Circuit Type Source ID Holding Time PDU Length R Priority LAN ID Variable Length Fields 1 1 1 1 1 1 1 1 1 ID Length 2 2 1 ID Length+1
Issue 01 (2011-10-30)
286
11 Layer 3 Features
Figure 11-23 shows the format of a Hello packet in a P2P network. Figure 11-23 Format of a P2P IIH
Intradomain Routeing Protocol Discriminator Length Indicator Version/Protocol ID Extension ID Length R R R PDU Type Version Reserved Maximum Area Address Reserved/Circuit Type Source ID Holding Time PDU Length Local Circuit ID Variable Length Fields
No. of Octets 1 1 1 1 1 1 1 1 1 ID Length 2 2 1
As shown in Figure 11-23, most fields in a P2P IIH are the same as those in a LAN IIH. The P2P IIH does not have the priority and LAN ID fields, but has a local circuit ID field. The local circuit ID indicates the local link ID. l LSP packet format Link State PDUs (LSPs) are used to exchange link-state information. There are two types of LSPs, that is, Level-1 LSPs and Level-2 LSPs. Level-1 IS-IS transmits Level-1 LSPs; Level-2 IS-IS transmits Level-2 LSPs; Level-1-2 IS-IS can transmit both Level-1 and Level-2 LSPs. Level-1 and Level-2 LSPs have the same format, as shown in Figure 11-24.
Issue 01 (2011-10-30)
287
11 Layer 3 Features
Figure 11-24 Format of a Level-1 or Level-2 LSP
No. of Octets IntradomainRouteingProtocolDiscriminator Length Indicator Version/Protocol IDExtension ID Length R R R PDU Type Version Reserved Maximum AreaAddress PDULength RemainingLifetime SequencyNumber Checksum R ATT OL IS Type Variable Length Fields 1 1 1 1 1 1 1 1 2 ID Length+2 4 2 1
The main fields are described as follows: OL: indicates LSDB overload. LSPs with the overload bit are still flooded on the network, but the LSPs are not used when routes that pass through a router configured with the overload bit are calculated. That is, after a router is configured with the overload bit, other routers ignore the router when performing the SPF calculation. Only the direct routes of the router are considered. As shown in Figure 11-25, packets from Router A to Router C are all forwarded by Router B. If the OL field is set to 1 on Router B, however, Router A considers that the LSDB of Router B is incomplete. Router A then forwards the packets to Router C through Router D and Router E, but the packets to the destination that is directly connected to Router B are forwarded normally. Figure 11-25 Schematic diagram of LSDB overload
RouterD
RouterE
Overload RouterA RouterB
RouterC
Issue 01 (2011-10-30)
288
11 Layer 3 Features
IS Type: indicates the type of IS-IS generating the LSP. It is used to specify whether the level of IS-IS is Level-1 or Level-2 (01 indicates Level-1; 11 indicates Level-2). l SNP Format Sequence Number PDUs (SNPs) describe the LSPs in all or part of the databases to synchronize and maintain all LSDBs. An SNP consists of a complete SNP (CSNP) and a partial SNP (PSNP). They are further divided into a Level-1 CSNP, a Level-2 CSNP, a Level-1 PSNP, and a Level-2 PSNP. A CSNP contains the summary of all LSPs in an LSDB. This maintains LSDB synchronization between neighboring routers. On a broadcast network, the DIS periodically sends CSNPs. The default interval for sending CSNPs is 10 seconds. On a point-to-point link, CSNPs are sent only when the neighbor relationship is established for the first time. Figure 11-26 shows the CSNP format. Figure 11-26 Format of a Level-1 or Level-2 CSNP
No. of Octets Intradomain Routeing Protocol Discriminator Length Indicator Version/Protocol ID Extension ID Length R R R PDU Type Version Reserved Maximum Area Address PDU Length Source ID Start LSP ID End LSP ID Variable Length Fields 1 1 1 1 1 1 1 1 2 ID Length+1 ID Length+2 ID Length+2
The main fields are described as follows: Source ID: indicates the system ID of the router that sends the SNP. Start LSP ID: indicates the ID of the first LSP in the CSNP. End LSP ID: indicates the ID of the last LSP in the CSNP. A PSNP lists only the sequence number of recently received LSPs. A PSNP can acknowledge multiple LSPs at a time. If an LSDB is not updated, the PSNP is also used to request a neighbor to send a new LSP. Figure 11-27 shows the PSNP format.
Issue 01 (2011-10-30)
289
11 Layer 3 Features
Figure 11-27 Format of a Level-1 or Level-2 PSNP
No. of Octets Intradomain Routeing Protocol Discriminator Length Indicator Version/Protocol ID Extension ID Length R R R PDU Type Version Reserved Maximum Area Address PDU Length Source ID Variable Length Fields 1 1 1 1 1 1 1 1 2 ID Length+1
CLV The variable length fields in a PDU are the multiple Code-Length-Values (CLVs). Figure 11-28 shows the CLV format. A CLV is also called the Type- Length-Value (TLV). Figure 11-28 CLV format
No. of Octets Code Length Value 1 1 Length
CLVs vary with PDU types, as shown in Table 11-14. Table 11-14 PDU types and CLV names CLV Code 1 2 4 6 7 8 9
Issue 01 (2011-10-30)
Name Area Addresses IS Neighbors (LSP) Partition Designated Level2 IS IS Neighbors (MAC Address) IS Neighbors (SNPA Address) Padding LSP Entries
Applied PDU Type IIH and LSP LSP L2 LSP LAN IIH LAN IIH IIH SNP
290
11 Layer 3 Features
CLV Code 10 128 129 130 131 132
Name Authentication Information IP Internal Reachability Information Protocols Supported IP External Reachability Information Inter-Domain Routing Protocol Information IP Interface Address
Applied PDU Type IIH, LSP, and SNP LSP IIH and LSP L2 LSP L2 LSP IIH and LSP
The CLVs with codes ranging from 1 to 10 are defined in ISO 10589 (two types are not listed in the table), and the other CLVs are defined in RFC 1195.
IS-IS Areas
l Two-Level structure To support large-scale routing networks, IS-IS adopts a two-level structure in a routing domain. A large domain can be divided into one or more areas. In general, Level-1 routers are located in an area, Level-2 routers are located among areas, and Level-1-2 routers are located between the Level-1 routers and the Level-2 routers. l Level-1 router A Level-1 router manages intra-area routing. It establishes neighbor relationships with only the Level-1 and Level-1-2 routers in the same area. It maintains a Level-1 LSDB. The LSDB contains routing information on the local area. A packet to a destination outside this area is forwarded to the nearest Level-1-2 router. l Level-2 router A Level-2 router manages inter-area routing. It can establish neighbor relationships with Level-2 routers or Level-1-2 routers in other areas. It maintains a Level-2 LSDB. The LSDB contains inter-area routing information. All Level-2 routers form the backbone network of the routing domain. They are responsible for communications between areas. The Level-2 routers in the routing domain must be in succession to ensure the continuity of the backbone network. Only Level-2 routers can exchange data packets or routing information with routers outside the routing domain. l Level-1-2 router A router, which belongs to both a Level-1 area and a Level-2 area, is called a Level-1-2 router. It can establish Level-1 neighbor relationships with Level-1 routers and Level-1-2 routers in the same area. It can also establish Level-2 neighbor relationships with Level-2 routers and Level-1-2 routers in other areas. A Level-1 router must be connected to other areas through a Level-1-2 router. A Level-1-2 router maintains two LSDBs, that is, a Level-1 LSDB and a Level-2 LSDB. The Level-1 LSDB is used for intra-area routing and the Level-2 LSDB is used for interarea routing.
Issue 01 (2011-10-30)
291

NOTE
11 Layer 3 Features
Level-1 routers in different areas cannot establish neighbor relationships. Level-2 routers can establish neighbor relationships with each other, regardless of the areas to which the Level-2 routers belong.
Interface level A Level-1-2 router may need to establish only a Level-1 neighbor relationship with the remote end and establish only a Level-2 neighbor relationship with the other remote end. You can set the level of an interface to restrict the setup of adjacencies on the interface. For example, only a Level-1 adjacency can be established on a Level-1 interface and only a Level-2 adjacency can be established on a Level-2 interface.
Figure 11-29 shows a network that runs IS-IS. The network is similar to an OSPF network typology with multiple areas. The entire backbone area contains all routers in Area 1 and Level-1-2 routers in other areas. Figure 11-29 IS-IS topology I
Area2 Area3 L1 L1/2 L2 backbone L2 L1/2 Area1
L2 L2 Area4 L1/2 L1 L1 L1/2
Area5 L1 L1 L1
Figure 11-30 shows another type of IS-IS topologies. All the successive Level-1-2 and Level-2 routers form the backbone area of IS-IS. In the topology, Level-2 routers belong to different areas, and Level-1-2 routers also belong to different areas. No area is defined as the backbone area.
Issue 01 (2011-10-30)
292
11 Layer 3 Features
Figure 11-30 IS-IS topology II
Area1 L1 L2 L1 L1/L2 Area2 L1/L2 L2 L2 Area3 Area4 L1
NOTE
The IS-IS backbone network does not refer to a specific area.
This networking scheme shows the difference between IS-IS and OSPF. For OSPF, inter-area routes are forwarded by the backbone area, and the SPF algorithm is used only in the same area. For IS-IS, both Level-1 and Level-2 routes are calculated through the SPF algorithm to generate the Shortest Path Tree (SPT).
IS-IS Network Types

IS-IS supports only two types of networks. According to physical links, IS-IS networks can be classified into the following types: l l Broadcast links: such as Ethernet and Token-Ring Point-to-point links: such as PPP and HDLC
For a Non-Broadcast Multi-Access (NBMA) network such as the ATM, you should configure its sub-interfaces as P2P interfaces. IS-IS cannot run on the Point to MultiPoint (P2MP) networks.
DIS and Pseudo Node

In a broadcast network, IS-IS needs to elect a Designated Intermediate System (DIS) from all the routers. The DISs of Level-1 and Level-2 are elected respectively. You can configure different priorities for DISs of different levels. The router with the highest priority is elected as the DIS. If there are multiple routers with the same highest priority in a broadcast network, the one with the largest MAC address is chosen. The DISs of different levels can be the same router or different routers. Unlike the DR election in OSPF, the DIS election in IS-IS has the following features: l l The router with the priority being 0 also takes part in the DIS election. When a new router that meets the requirements of being a DIS joins the broadcast network, the router is selected as the new DIS, and the original pseudonode is deleted. This causes LSP flooding.
Issue 01 (2011-10-30)
11 Layer 3 Features
In an IS-IS broadcast network, the routers (including non-DIS routers) of the same level in a network segment set up adjacencies, which is different from that of OSPF. Figure 11-31 shows the networking. Figure 11-31 DISs and adjacencies in an IS-IS broadcast network
L1/L2
L1/L2
L1 Adjacencies L2 Adjacencies L1 DIS L2 DIS
A DIS is used to create and update pseudo nodes. It also generates LSPs of the pseudo nodes. The LSPs describe the available routers on the network. The pseudo node is used to simulate the virtual node in the broadcast network and is not an actual router. In IS-IS, a pseudo node is identified by the system ID of the DIS and the 1-byte Circuit ID (its value is not 0). With pseudo nodes, the network topology is simplified and LSPs are shortened. When the network changes, the number of generated LSPs is reduced. As a result, the SPF consumes fewer resources.
NOTE
In an IS-IS broadcast network, although all the routers set up adjacencies with each other, the LSDBs are synchronized by the DISs.
Establishment of the IS-IS Neighbor Relationship

Two IS-IS routers need to establish the neighbor relationship before exchanging packets to implement routing. On different networks, the modes for establishing IS-IS neighbors are different. l Establishment of a neighbor relationship on a broadcast link Figure 11-32 Networking diagram of a broadcast link
RouterA
RouterB
RouterC
RouterD
Issue 01 (2011-10-30)
294
11 Layer 3 Features
Router A, Router B, Router C, and Router D are Level-2 routers. Router A is newly added to the broadcast network. Figure 11-32 lists the process of establishing the neighbor relationship between Router A and Router B. The process of establishing the neighbor relationship between Router A and Router C or Router D is similar to that between Router A and Router B, and is not mentioned here. Figure 11-33 Process of establishing a neighbor relationship on a broadcast link
RouterA RouterB
SYS id:1111.1111.1111
neighbor Router B established
SYS id:2222.2222.2222 L2 LAN IIH ( sys id:1111.1111.1111 neighbor:null ) neighbor Router A initialized L2 LAN IIH ( sys id:2222.2222.2222 neighbor:Router A )
L2 LAN IIH ( sys id:1111.1111.1111 neighbor:Router B ) L2 LAN IIH L2 LAN IIH
neighbor Router A established
Router A broadcasts a Level-2 LAN IS-IS Hello PDU. After receiving the PDU, Router B sets its neighbor status with Router A to Initial. Then, Router B responds Router A with a Level-2 LAN IIH packet indicating that Router A is a neighbor of Router B. On receiving the IIH packet, Router A sets its neighbor status with Router B to Up. The network is a broadcast network, so a DIS needs to be elected. After the neighbor relationship is established, routers wait for two intervals for sending Hello packets to elect the DIS. The IIH packets exchanged by the routers contain the Priority field. The router with the highest priority is elected as the DIS. If the routers have the same priority, the router with the largest interface MAC address is elected as the DIS. l Establishment of a neighbor relationship on a P2P link Unlike the establishment of a neighbor relationship on a broadcast link, the establishment of a neighbor relationship on a P2P link is classified into two modes, that is, 2-way mode and 3-way mode. 2-way mode Upon receiving an IS-IS Hello packet, a router unidirectionally sets up the neighbor relationship. 3-way mode A neighbor relationship is established after IS-IS Hello PDUs are sent for three times, which is similar to the establishment of a neighbor relationship on a broadcast link.
NOTE
The three-way handshake mechanism of IS-IS is specifically introduced in other chapters.
Basic rules for establishing an IS-IS neighbor relationship are as follows:

11 Layer 3 Features
l l l
Only the neighboring routers of the same level can set up the neighbor relationship with each other. For Level-1 routers, their area IDs must be the same. Routers are on the same network segment.
Network types of IS-IS interfaces on both ends of a link must be consistent; otherwise, the neighbor relationship cannot be established. By simulating Ethernet interfaces as P2P interfaces, you can establish a neighbor relationship on a P2P link. IS-IS runs on the data-link layer and is initially designed for CLNP. Therefore, the establishment of an IS-IS neighbor relationship is not related to IP addresses. In the implementation of the device, IS-IS runs only over IP. Thus, IS-IS needs to check the IP address of its neighbor. If secondary IP addresses are assigned to the interfaces, the routers can still set up the IS-IS neighbor relationship only when either the primary IP addresses or secondary IP addresses are on the same network segment. When IP address unnumbered is not configured, if the IP address of its neighbor and the address of the interface through which the router receives packets are not on the same network segment, the neighbor relationship cannot be set up. The IP unreachability is thus prevented. The neighbor relationship can be set up if you configure the router not to check the IP addresses contained in received Hello packets. l l For P2P interfaces, you can configure the interfaces not to check the IP addresses. For Ethernet interfaces, you must simulate Ethernet interfaces as P2P interfaces and then configure the interfaces not to check the IP addresses.
Process of Exchanging IS-IS LSPs

l LSP flooding The flooding of LSPs is a mode in which a router sends an LSP to its neighbors and the neighbors send the received LSP to their respective neighbors except the router that first sends the LSP. In this manner, the LSP is flooded among the routers of the same level. Through the flooding, each router of the same level has the same LSP information and keeps a synchronized LSDB. Each LSP has a 4-byte sequence number. When a router is started, the sequence number of the first LSP sent by the router is 1. When a new LSP is generated, the sequence number of the LSP is equal to the sequence number of the previous LSP plus 1. The greater the sequence number, the newer the LSP. l Causes of LSP generation All routers in the IS-IS routing domain can generate LSPs. The following events trigger the generation of a new LSP: A neighbor is Up or Down. A related interface is Up or Down. Imported IP routes change. Inter-area IP routes change. An interface is assigned with a new metric value. Periodical updates occur. l Processing of a new LSP received from a neighbor 1.
Issue 01 (2011-10-30)
The router installs the LSP to the LSDB and marks it with flooding.
11 Layer 3 Features
2. 3. l
The router sends the LSP to all interfaces except the interface that receives the LSP. The neighbors flood the LSP to their neighbors.
Process of synchronizing LSDBs between a newly added router and DIS Figure 11-34 Process of updating LSDBs on a broadcast link
RouterA RouterC RouterB( DIS)
CSNP Router A.00-00 Router B.00-00 Router B.01-00 Router C.00-00 LSP Router A.00-00 Router B.00-00 Router B.01-00
LSP Router C.00-00
PSNP Router A.00-00 Router B.00-00 Router B.01-00
A newly added Router C sends Hello packets to establish neighbor relationships with the other routers in the broadcast domain. For details, see "Establishment of a neighbor relationship on a broadcast link." After setting up the neighbor relationships with other routers, Router C sends its LSP to the following multicast addresses after the LSP timer expires: Level-1: 01-80-C2-00-00-14 Level-2: 01-80-C2-00-00-15 All neighbors on the network can receive the LSP. The DIS on the network segment adds the LSP received from Router C to its LSDB. After the CSNP timer expires, the DIS sends CSNPs to synchronize the LSDBs on the network. By default, CSNPs are sent at intervals of 10 seconds. After Router C receives the CSNPs from the DIS, Router C checks its LSDB and sends a PSNP to request the LSPs it does not have. After receiving the PSNP, the DIS sends the required LSPs to synchronize LSDBs. l Process of updating the LSDB of the DIS When the DIS receives an LSP, it searches the LSDB for the related records. If the DIS does not find the LSP in its LSDB, it adds the LSP to its LSDB and broadcasts the contents of the new LSDB.
11 Layer 3 Features
If the sequence number of the received LSP is greater than the sequence number of the corresponding LSP in the LSDB, the DIS replaces the LSP with the received LSP in the LSDB, and broadcasts the contents of the new LSDB. If the sequence number of the received LSP is smaller than the sequence number of the corresponding LSP in the LSDB, the DIS sends the LSP in the LSDB to the inbound interface. If the sequence number of the received LSP is equal to the sequence number of the corresponding LSP in the LSDB, the DIS compares the Remaining Lifetime of the two LSPs. If the received LSP has a smaller Remaining Lifetime than that of the corresponding LSP in the LSDB, the DIS replaces the LSP in the LSDB with the received LSP, and broadcasts the contents of the new LSDB. If the sequence number of the received LSP is equal to the sequence number of the corresponding LSP in the LSDB, the DIS compares the Remaining Lifetime of the two LSPs. If the received LSP has a greater Remaining Lifetime than that of the corresponding LSP in the LSDB, the DIS sends the LSP in the LSDB to the inbound interface. If both the sequence number and the Remaining Lifetime of the received LSP and the corresponding LSP in the LSDB are the same, the DIS compares the checksum of the two LSPs. If the received LSP has a greater checksum than that of the corresponding LSP in the LSDB, the DIS replaces the LSP in the LSDB with the received LSP, and advertises the contents of the new LSDB. If both the sequence number and the Remaining Lifetime of the received LSP and the corresponding LSP in the LSDB are the same, the DIS compares the checksum of the two LSPs. If the received LSP has a smaller checksum than that of the corresponding LSP in the LSDB, the DIS sends the LSP in the LSDB to the inbound interface. If both the sequence number, Remaining Lifetime, and checksum of the received LSP and that of the corresponding LSP in the LSDB are the same, the LSP is not forwarded. l Process of synchronizing the LSDB on a P2P link Figure 11-35 Process of updating the LSDB on a P2P link
RouterA
PPP
RouterB
LSP Router A.00-00 Retransmission times out LSP Router A.00-00
PSNP Router A.00-00 Resend response packet PSNP Router A.00-00
Issue 01 (2011-10-30)
298
11 Layer 3 Features
1.
When the neighbor relationship is set up for the first time, a router sends a CSNP to its neighbor. If the LSDB of the neighbor and the CSNP are not synchronized, the neighbor sends PSNP requests for a required LSP. The router sends the required LSP to the neighbor and starts the LSP retransmission timer. The router then waits for a PSNP from the neighbor as an acknowledgement of the receiving of the LSP. If the router does not receive the PSNP from the neighbor after the LSP retransmission timer expires, it resends the LSP.
NOTE
2.
3.
A PSNP on a P2P link functions as follows: l It is used as an Ack packet to acknowledge the received LSP. l It is used as a request packet to require LSPs.
Process of updating the LSDB If the sequence number of the received LSP is greater than the sequence number of the corresponding LSP in the LSDB, the router adds the LSP to its LSDB. The router then sends a PSNP to acknowledge the received LSP. At last, the router sends the LSP to all its neighbors except the neighbor that sends the LSP. If the sequence number of the received LSP is smaller than the sequence number of the corresponding LSP in the LSDB, the router directly sends its LSP to the neighbor and waits for a PSNP from the neighbor as the acknowledgement. If the sequence number of the received LSP is the same as the sequence number of the corresponding LSP in the LSDB, the router compares the Remaining Lifetime of the two LSPs. If the received LSP has a smaller Remaining Lifetime than that of the corresponding LSP in the LSDB, the router adds the LSP to its LSDB. The router then sends a PSNP to acknowledge the received LSP. At last, the router sends the LSP to all its neighbors except the neighbor that sends the LSP. If the sequence number of the received LSP is the same as the sequence number of the corresponding LSP in the LSDB, the router compares the Remaining Lifetime of the two LSPs. If the received LSP has a greater Remaining Lifetime than that of the corresponding LSP in the LSDB, the router directly sends its LSP to the neighbor and waits for a PSNP from the neighbor. If both the sequence number and the Remaining Lifetime of the received LSP and the corresponding LSP in the LSDB are the same, the router compares the checksum of the two LSPs. If the received LSP has a greater checksum than that of the corresponding LSP in the LSDB, the router adds the LSP to its LSDB. The router then sends a PSNP to acknowledge the received LSP. At last, the router sends the LSP to all its neighbors except the neighbor that sends the LSP. If both the sequence number and the Remaining Lifetime of the received LSP and the corresponding LSP in the LSDB are the same, the router compares the checksum of the two LSPs. If the received LSP has a smaller checksum than that of the corresponding LSP in the LSDB, the router directly sends its LSP to the neighbor and waits for a PSNP from the neighbor. If both the sequence number, Remaining Lifetime, and checksum of the received LSP and the corresponding LSP in the LSDB are the same, the LSP is not forwarded.
Issue 01 (2011-10-30)
299
11 Layer 3 Features
11.7.8.5 IS-IS Multi-instance and Multi-process

For the routers that support the VPN, you can associate each IS-IS process with a specific VPN instance. Thus, you can configure multiple IS-IS processes to be associated with multiple VPN instances at the same time. l l IS-IS multi-instance indicates that you can configure multiple IS-IS instances on the same router. IS-IS multi-process indicates that you can create multiple IS-IS processes in a VPN or a public network. The multi-process feature allows a set of interfaces to be associated with a specific ISIS process. This ensures that the specific IS-IS process performs all the protocol operations only on the set of interfaces. Thus, multiple IS-IS processes can work on a single router and each process is responsible for a unique set of interfaces. IS-IS multi-processes share an RM routing table. IS-IS multi-instances use the RM routing tables of VPNs. Each VPN has its own RM routing table. When an IS-IS process is created, it can be associated with a VPN instance. Then, the IS-IS process belongs to the VPN and processes events only in the VPN. The IS-IS process is deleted when the associated VPN is deleted. For easy management and effective control, IS-IS supports multi-process and multi-instance features. In the scenario where IS-IS is applied to users on private networks, after a VPN is created, interfaces bound to the VPN and routes in the VPN are isolated from other VPNs and public network data. In this case, you can adopt IS-IS multi-instance to deploy IS-IS in the VPN. For the routers that support the VPN, each IS-IS process is associated with a specific VPN instance. All the interfaces attached to an IS-IS process, therefore, should be associated with the VPN instance that this IS-IS process is associated to. At present, the VPN instance is maintained by the VPN module. Thus, IS-IS multi-instance is implemented by associating an IS-IS process with a VPN instance when the IS-IS process is created. When configuring IS-IS multi-instance and multi-process, note the following: l When creating IS-IS multi-instances, associate an IS-IS process with a VPN instance when the IS-IS process is created. If an IS-IS process is not associated with a VPN instance when the IS-IS process is created, the association cannot be configured later. An IS-IS process that is already associated with a VPN instance cannot be associated with another VPN instance. Multiple IS-IS processes can be associated with one VPN instance. The interfaces where IS-IS multi-instance needs to be enabled must be associated with the same VPN instance as IS-IS. The IS-IS process associated with a VPN instance belongs to the VPN. Thus, the IS-IS process is deleted when the VPN is deleted. Routes from different VPNs cannot be imported to each other.
l l l l l
11.7.8.6 IS-IS Route Leaking

With the route leaking function, Level-1-2 IS-IS advertises the known routing information about other Level-1 and Level-2 areas to the specified Level-1 areas.
11 Layer 3 Features
Normally, the intra-area routes are managed by Level-1 routers. All Level-2 and Level-1-2 routers form a successive backbone area. The Level-1 area can be connected to only the backbone area. The Level-1 areas cannot be connected to each other. Routing information in a Level-1 area is advertised to a Level-2 area through a Level-1-2 router. That is, the Level-1-2 router encapsulates the learned Level-1 routing information into a Level-2 LSP and floods the Level-2 LSP to other Level-2 and Level-1-2 routers. To reduce the size of routing tables, Level-2 routers, by default, do not advertise the learned routing information of Level-1 areas and that of the backbone area to Level-1 areas. The Level-1 routers, therefore, cannot know the routing information outside the area. In this manner, the Level-1 routers cannot select the optimal route to the destination outside the area. To solve the preceding problem, IS-IS route leaking is introduced. By configuring Access Control Lists (ACLs) and route-policies and marking routes with tags on Level-1-2 routers, you can select eligible routes. Then, a Level-1-2 router can advertise some routing information of other Level-1 areas and the backbone area to its Level-1 area. Figure 11-36 Networking for route leaking
RouterA Level-1 1.1.1.1/24 2.2.2.1/24 cost 10 2.2.2.2/24 cost 10 5.5.5.1/24 3.3.3.1/24 3.3.3.2/24 RouterB RouterD Level-1 Level-1-2 Area10 Area20 cost 10 RouterE 5.5.5.2/24 Level-2 cost 10 RouterC Level-1-2 1.1.1.2/24 cost 50 4.4.4.1/24 4.4.4.2/24 6.6.6.2/24 6.6.6.1/24
cost 10 RouterF Level-2
l l
Router A, Router B, Router C, and Router D belong to Area 10; Router A and Router B are Level-1 routers; Router C and Router D are Level-1-2 routers. Router E and Router F are Level-2 routers and belong to Area 20.
If Router A sends a packet to Router F, the selected optimal route should be Router A -> Router B -> Router D -> Router E -> Router F. This is because the cost of the route is 40. Check the route on Router A to view the path of packets sent to Router F, and you can find that the selected route is Router A -> Router C -> Router E -> Router F, of which the cost is 70. Thus, the route is not the optimal route from Router A to Router F. Router A does not know the routes outside the local area, so the packets sent by Router A to other network segments are sent through the default route generated by the nearest Level-1-2 router. In this case, you can enable route leaking on the Level-1-2 routers, that is, Router C and Router D. Then, check the route and you can find that the selected route is Router A -> Router B -> Router D -> Router E -> Router F, which is the optimal route from Router A to Router F.
Issue 01 (2011-10-30)
301
11 Layer 3 Features
11.7.8.7 IS-IS Fast Convergence

IS-IS fast convergence is an extended feature of IS-IS implemented to speed up the convergence of routes. It includes the following: l I-SPF Incremental SPF (I-SPF) recalculates only the routes of the changed nodes rather than all the nodes when the network topology changes. This speeds up the calculation of routes. l PRC Partial Route Calculation (PRC) calculates only the changed routes when the routes on the network change. l l LSP fast flooding LSP fast flooding speeds up the flooding of LSPs. Intelligent timer The first timeout period of the timer is fixed. If an event that triggers the timer happens when the timer is set and does not expire, the interval set by the intelligent timer increases next time. The intelligent timer is applicable to the LSP generation and SPF calculation.
I-SPF (Incremental SPF)

In ISO 10589, the Dijkstra algorithm is adopted to calculate routes. When a node changes on the network, this algorithm is used to recalculate all routes. The calculation lasts a long time and consumes too many CPU resources, thus affecting the convergence speed. I-SPF improves this algorithm. Except for the first time, only changed nodes instead of all nodes are involved in calculation. The SPT generated at last is the same as that generated by the previous algorithm. This decreases the CPU usage and speeds up the network convergence.
PRC (Partial Route Calculation)

Similar to I-SPF, PRC calculates only the changed routes. PRC, however, does not calculate the shortest path. It updates the routes based on the SPT calculated by I-SPF. In route calculation, a leaf represents a route, and a node represents a router. If the SPT changes after I-SPF calculation, PRC processes all the leaves only on the changed node. If the SPT remains unchanged, PRC processes only the changed leaves. For example, if IS-IS is enabled on an interface of a node, the SPT calculated by I-SPF remains unchanged. In this case, PRC updates only the routes of this interface, thus consuming less CPU resources. PRC working with I-SPF further improves the convergence performance of the network. It is an improvement of the original SPF algorithm.
NOTE
In the implementation of device, only I-SPF and PRC are used to calculate IS-IS routes.
LSP Fast Flooding

When IS-IS receives new LSPs from other routers, it updates the LSPs in the LSDB and periodically floods out the updated LSPs according to a timer.
11 Layer 3 Features
LSP fast flooding improves the preceding mode. When the device configured with this feature receives one or more new LSPs, it floods out the LSPs whose amount is smaller than the specified number before calculating routes. This significantly improves the network convergence speed.
Intelligent Timer
Although the route calculation algorithm is improved, the long interval for triggering the route calculation also affects the convergence speed. You can shorten the interval by using a millisecond-level timer. Frequent network changes, however, also consume too many CPU resources. The SPF intelligent timer addresses these problems. In general, an IS-IS network running normally is stable. The probability of the occurrence of many network changes is very low, and IS-IS does not frequently calculate routes. The period for triggering the route calculation is very short (millisecond level). If the topology of the network changes very often, the interval set by the intelligent timer increases with the calculation times to avoid too much CPU consumption. The LSP generation intelligent timer is similar to the SPF intelligent timer. When the LSP generation intelligent timer expires, the system generates a new LSP based on the current topology. The original mechanism adopts a timer with uniform intervals, and thus fast convergence and low CPU consumption cannot be achieved. Thus, the LSP generation timer is designed as an intelligent timer to respond to emergencies (such as the interface is Up or Down) quickly and speed up the network convergence. In addition, when the network changes very often, the interval for the intelligent timer becomes longer to avoid too much CPU consumption.
11.7.8.8 Priority-based IS-IS Convergence

Priority-based IS-IS convergence ensures that specific routes converge first in the case of a great number of routes. Different routes can be set with different convergence priorities. This allows important routes to converge first and thus improves network reliability. Priority-based IS-IS convergence enables specific routes (such as routes that match the specified IP prefix) to converge first. Therefore, users can assign a high convergence priority to routes for key services so that these routes can converge fast. This decreases impact on key services.
11.7.8.9 IS-IS LSP Fragment Extension

When the LSPs to be advertised by IS-IS contain much information, they are advertised in multiple LSP fragments of the same system. As defined in RFC 3786, virtual system IDs can be configured and virtual LSPs that carry routing information can be generated for IS-IS. The IS-IS LSP fragment extension attribute allows an IS-IS router to generate more LSP fragments and carry more IS-IS information.
Terms
l Originating system The originating system is a router that runs the IS-IS protocol. A single IS-IS process can advertise its LSPs as multiple "virtual" routers, and the originating system represents the "real" IS-IS process. l Normal system ID It is the system ID of the originating system.
11 Layer 3 Features
Additional system ID The additional system ID, assigned by network administrators, is used to generate additional or extended LSP fragments. Up to 256 additional or extended LSP fragments can be generated. Like the normal system ID, the additional system ID must be unique in the routing domain.
Virtual system The system, identified by an additional system ID, is used to generate extended LSP fragments. These fragments carry the additional system IDs in their LSP IDs.
Principle
IS-IS LSP fragments are identified by the LSP Number field in their LSP IDs. The LSP Number field is 1 byte. Thus, an IS-IS process can generate a maximum of 256 fragments, carrying a limited number of routes (30,000 routes can be carried when the fragment length is 1497 bytes). With fragment extension, more information can be carried. Each system ID represents a virtual system that can generate 256 LSP fragments. With more additional system IDs (up to 50 virtual systems), an IS-IS process can generate a maximum of 13056 LSP fragments. When a virtual system and fragment extension are configured, an IS-IS router adds the contents that cannot be contained in the LSPs advertised by the originating system to the LSPs of the virtual system, and notifies other routers of the relation between the virtual system and itself through a special TLV.
IS Alias ID TLV
A special TLV, IS Alias ID TLV, is defined in RFC 3786. Table 11-15 IS Alias ID TLV Field Type Length System ID Pseudonode number sub-TLVs length sub-TLVs Length 1 byte 1 byte 6 bytes 1 byte 1 byte 0 to 247 bytes Description Indicates the TLV type. If the value is 24, it indicates the IS Alias ID TLV. Indicates the length of Value in the TLV. System ID pseudonode number sub-TLVs length sub-TLVs
In whatever operation mode, the originating system and virtual system send the LSPs with the fragment number being 0 carrying IS Alias ID TLV to indicate the originating system.
Issue 01 (2011-10-30)
304
11 Layer 3 Features
Operation Modes
The IS-IS router can run the LSP fragment extension feature in the following modes: Figure 11-37 Networking for LSP fragment extension
RouterA1
RouterB
RouterA
RouterA2
Mode-1 It is used when some routers on the network do not support the LSP fragment extension. In this mode, virtual systems participate in the SPF calculation. The originating system advertises LSPs containing information about links to each virtual system. Similarly, each virtual system advertises LSPs containing information about links to the originating system. In this manner, the virtual systems look like the actual routers that are connected to the originating system on the network. Mode-1 is a transitional mode for the earlier versions that do not support fragment extension. In the earlier versions, IS-IS cannot identify the Alias ID TLV. Thus, the LSP sent by a virtual system must look like a common IS-IS LSP. The LSP sent by a virtual system contains the same area address and overload bit as that in the common LSP. If the LSPs sent by a virtual system contain TLVs specified in other features, they must be the same as those in common LSPs. The virtual system carries neighbor information specifying that the neighbor is the originating system, with the metric being the maximum value minus 1; the originating system carries neighbor information specifying that the neighbor is the virtual system, with the metric being 0. This ensures that the virtual system is the downstream node of the originating system when other routers calculate routes. As shown in Figure 11-37, Router B does not support the LSP fragment extension; Router A is set to support the LSP fragment extension in mode-1; Router A1 and Router A2 are virtual systems of Router A. Router A1 and Router A2 send LSPs carrying some routing information of Router A. After receiving LSPs from Router A, Router A1, and Router A2, Router B considers that there are three individual routers at the peer end and calculates routes normally. Because the cost of the route from Router A to Router A1 and the cost of the route from Router A to Router A2 are both 0s, the cost of the route from Router B to Router A is equal to the cost of the route from Router B to Router A1.
Mode-2 It is used when all the routers on the network support the LSP fragment extension. In this mode, virtual systems do not participate in the SPF calculation. All the routers on the network know that the LSPs generated by the virtual systems actually belong to the originating system.
Issue 01 (2011-10-30)
305
11 Layer 3 Features
IS-IS working in mode-2 identifies IS Alias ID TLV, which is used to calculate the SPT and routes. As shown in Figure 11-37, Router B supports the LSP fragment extension; Router A is set to support the LSP fragment extension in mode-2; Router A1 and Router A2 send LSPs carrying some routing information of Router A. When receiving LSPs from Router A1 and Router A2, Router B obtains IS Alias ID TLV and knows that the originating system of Router A1 and Router A2 is Router A. Router B then considers that information advertised by Router A1 and Router A2 belongs to Router A. No matter LSP fragment extension is set to mode-1 or mode-2, both LSPs in mode-1 and LSPs in mode-2 can be resolved. If LSP fragment extension is not supported, only LSPs in mode-1 can be resolved. Table 11-16 Comparison between mode-1 and mode-2 LSP Content\Mode IS Alias ID area overload bit IS NBR/IS EXTENDED NBR Routing ATT bits P bit Mode-1 Yes Yes Yes Yes Yes must 0 must 0 Mode-2 Yes No Yes No Yes must 0 must 0
Process
After LSP fragment extension is configured, if information is lost because LSPs are of full lengths, the system prompts that the IS-IS router should be restarted. After being restarted, the originating system loads as much routing information as possible. The remaining information is added to the LSPs of the virtual systems for transmission.
Application Environment
NOTE
If there are devices of other manufacturers on the network, the LSP fragment extension must be set to mode-1. Otherwise, devices of other manufacturers cannot identify the LSPs.
It is recommended that you configure the LSP fragment extension and virtual systems before setting up IS-IS neighbors or importing routes. If you set up IS-IS neighbors or import routes, which causes IS-IS to carry much information that cannot be loaded through 256 fragments, you must configure the LSP fragment extension and virtual systems. The configurations, however, takes effect only after you restart the IS-IS router.
11.7.8.10 IS-IS Administrative Tag

Administrative tags control the advertisement of IP prefixes in the IS-IS domain. The administrative tag carries administrative information about an IP address prefix, which simplifies management. It is used to control the importing of routes of different levels and
11 Layer 3 Features
different areas, and control different routing protocols and IS-IS multi-instances running on the same router. The value of an administrative tag is associated with certain attributes. When cost-style is wide, wide-compatible or compatible, if IS-IS advertises an IP address prefix with these attributes, it adds the administrative tag to the TLV in the prefix. In this manner, the tag is flooded with the prefix throughout the routing domain.
11.7.8.11 Dynamic Hostname Exchange Mechanism

The dynamic hostname exchange mechanism provides a mapping from the hostname to system ID for IS-IS routers. IS-IS was first designed by the ISO for the CLNS; thus, its unique address encoding method is retained. Information about IS-IS neighbors and LSDBs on an IS-IS router, with hostname exchange disabled, is represented by a system ID with 12 hexadecimal numbers, for example, aaaa.eeee. 1234. This representation, however, is complicated and not easy to use. To maintain and manage IS-IS networks easily, the dynamic hostname exchange mechanism is introduced. This dynamic hostname information is advertised in the form of a dynamic hostname TLV (type 137) in LSPs. The dynamic hostname exchange mechanism also provides a service to associate a host name with the Designated IS (DIS) on a broadcast network. Then, this mechanism advertises this association through LSPs in the form of a dynamic hostname TLV. In the implementation of MA5600T/MA5603T, routers where IS-IS dynamic hostname mapping is enabled add the Dynamic Hostname TLV (TLV type 137) that records the local host name to the LSPs they generate before sending the LSPs out. Dynamic Hostname TLV (TLV type 137) includes the following fields: l l l Type: indicates the dynamic hostname exchange mechanism. Length: indicates the total length of the value field. Value: indicates a character string of 1 to 255 characters.
The Dynamic Hostname TLV is optional and can be inserted anywhere in an LSP. The hostname value cannot be null. A router determines whether to carry the TLV in sending LSPs; the router that receives the LSPs determines whether to ignore the TLV or obtain the TLV for its mapping table.
Implementation
l Matching rules The dynamic hostname abides by the longest match rule. System ID+NSEL is first compared. If it doesn't match, the system ID is then compared. l l l
Issue 01 (2011-10-30)
Transmission of the dynamic hostname The dynamic hostname can be carried by the original LSP only. Transmission of the DIS dynamic hostname The DIS dynamic hostname is transmitted through the LSPs generated by the DIS. Priority of the dynamic hostname
11 Layer 3 Features
The dynamic hostname is prior to the static hostname. When both a dynamic hostname and a static hostname are configured, the dynamic hostname replaces the static hostname. l Configuration and resolution of the dynamic hostname The dynamic hostname can be up to 64 bytes in length and a maximum of 255-byte contents can be resolved.
In maintenance and management, the hostname is easier to identify and memorize than the system ID. After this function is configured, it is the hostname instead of the system ID displayed for the router. The hostname exchange mechanism implemented on the MA5600T/MA5603T includes dynamic hostname mapping and static hostname mapping. The system ID is replaced by the hostname in the following cases: l When an IS-IS neighbor is displayed, the system ID of the IS-IS neighbor is replaced by the dynamic hostnames. If the IS-IS neighbor is the DIS, then the system ID of the DIS is replaced by the dynamic hostnames of the neighbor. When an LSP in the IS-IS LSDB is displayed, the system ID in the LSP ID is replaced by the dynamic hostname of the router that advertises the LSP. When details about the IS-IS LSDB are displayed, the Host Name field is included for the LSP generated by the router where dynamic hostname exchange is enabled; the system ID is replaced by the dynamic hostname of the IS-IS neighbor.
l l
11.7.8.12 IS-IS HA
IS-IS HA includes hot standby, data backup, command line backup, batch backup, and real-time backup. IS-IS backs up data from the Active Main Board (AMB) to the Standby Main Board (SMB). Whenever the AMB fails, the SMB becomes active and takes over the AMB. IS-IS, therefore, can keep working normally.
Basic Concepts
l l Data backup It indicates backup of data of processes and interfaces. Command line backup If the AMB processes successfully, it sends the command lines to the SMB for processing. If the AMB fails to process, it records in the log that the command lines fail to take effect and does not send the command lines to the SMB for processing. If the SMB fails to process, the failure is recorded in the log.
Hot Standby
The IS-IS Hot Standby (HSB) feature is supported on the devices with a distributed structure. In the running process of IS-IS HSB, IS-IS configurations on the AMB and those on the SMB are consistent. When the AMB/SMB switchover occurs, IS-IS on the new AMB performs GR. The new AMB resends a request for setting up the neighbor relationship to neighbors to synchronize LSDBs. Traffic, therefore, is not affected.
11 Layer 3 Features
Batch Backup
l Backing up data in batches When the SMB is installed, all data of the AMB is backed up to the SMB. No configuration can be changed during batch backup. l Backing up command lines in batches When the SMB is installed, all configurations of the AMB are backed up to the SMB at a time. No configuration can be changed during batch backup.
Real-time Backup
l l Real-time backup of data It indicates real-time backup of changed data of processes and interfaces to the SMB. Real-time backup of command lines It indicates that command lines that are run successfully on the AMB are backed up to the SMB.
11.7.8.13 IS-IS 3-Way Handshake

IS-IS introduces the 3-way handshake mechanism on P2P links to ensure a reliable data link layer. According to ISO 10589, the 2-way handshake mechanism of IS-IS uses Hello packets to set up P2P adjacencies between neighbors. Once the router receives a Hello packet from its peer, it regards the status of the peer as Up and sets an adjacency with the peer. This mechanism has distinct disadvantages. When two or more links exist between two routers, an adjacency can still be set up when one link is Down and the other is Up in the same direction. The parameters of the other link, however, are also used in SPF calculation. The router does not detect any faults of the link that is in the Down state and still tries forwarding packets through this link. The 3-way handshake mechanism solves these problems on P2P links. In 3-way handshake mode, the router regards the neighbor as Up only after confirming that the neighbor receives the packet that it sends and then sets up an adjacency with the neighbor. In addition, the 3-way handshake mechanism adopts the 32-bit Extended Local Circuit ID field. This extends the original 8-bit Extended Local Circuit ID field and P2P links increase to more than 255 in quantity.
NOTE
By default, the 3-way handshake mechanism of IS-IS is implemented on P2P links, as defined in RFC 3373.
11.7.8.14 IS-IS GR
IS-IS Graceful Restart (GR) implements non-stop forwarding by extending IS-IS to support the GR capability. It is one of the high availability (HA) technologies. RFC 3847 defines the IS-IS GR standard. IS-IS is a link state routing protocol. All routers in an area must maintain the same network topologies, that is, the same LSDBs. After the master/slave switchover, no neighbor information is stored on the restarted router. Thus, the first Hello packets sent by the router do not contain the neighbor list. After receiving
11 Layer 3 Features
the Hello packets, the neighbor checks the 2-way neighbor relationship and finds that it is not in the neighbor list of the Hello packets sent by the router. Thus, the neighbor relationship is interrupted. The neighbor then generates new LSPs and floods the topology changes to all other routers in the area. Routers in the area then calculate routes based on the new LSDBs, which leads to route interruption or routing loops. Because no LSDB is stored on the restarted router, the router needs to synchronize its LSDB with those of the neighbors after the master/slave switchover. If IS-IS is not restarted in GR mode, IS-IS neighbor relationships are reset and LSPs are regenerated and flooded. This triggers the SPF calculation in the entire area, which causes route flapping and forwarding interruption in the area. The IETF defined the GR standard, RFC 3847, for IS-IS. The restart of the protocol is processed for both the reserved FIB tables and unreserved FIB tables. Thus, the route flapping and interruption of the traffic forwarding caused by the restart can be avoided. When a router fails, neighbors at the routing protocol layer detect that their neighbor relationships are Down and then become Up again after a period of time. This is the flapping of neighbor relationships. The flapping of neighbor relationships causes route flapping, which leads to black hole routes on the restarted router or causes data services from the neighbors to be looped on the restarted router. This decreases the reliability on the network. GR is thus introduced to address route flapping.
Basic Concepts of IS-IS GR

IS-IS GR involves two roles, namely, GR restarter and GR helper. l l GR restarter The GR restarter refers to the router that restarts in GR mode. GR- helper The GR helper refers to another GR router that helps the restarter to complete the GR process. The GR restarter must have the capability of the GR helper.
NOTE
By default, the device supports the GR helper.
To implement GR, IS-IS introduces the restart Type-Length-Value (TLV), T1 timer, T2 timer, and T3 timer.
Restart TLV
The restart TLV is an extended part of an IS-to-IS Hello (IIH) PDU. All IIH packets of the router that supports IS-IS GR contains the restart TLV. The restart TLV carries the parameters for the protocol restart. Figure 11-38 shows the format of the restart TLV.
Issue 01 (2011-10-30)
310
11 Layer 3 Features
Figure 11-38 Format of the Restart TLV
3 4 5 Type(211) Length(1 to 9) SA
Reserved
RA
RR
Remaining Time
Restarting Neighbor System ID
Table 11-17 describes the fields of the restart TLV. Table 11-17 Description of the fields of the restart TLV Field Type Length RR Length 1 byte 1 byte 1 bit Description Indicates the TLV type. If the value is 211, the TLV is the restart TLV. Indicates the length of the TLV. Indicates the restart request bit. A router sends an RR packet to notify the neighbors of its restarting or starting and to require the neighbors to retain the current IS-IS adjacency and return CSNPs. Indicates the restart acknowledgement bit. A router sends an RA packet to respond to the RR packet. Indicates the suppress adjacency advertisement bit. The starting router uses an SA packet to require its neighbors to suppress the broadcast of their neighbor relationships to prevent routing loops. Indicates the time during which the neighbor does not reset the adjacency. The length of the field is 2 bytes. The time is measured in seconds. When RA is reset, the value is mandatory. Indicates the system ID of the neighboring router that responds to the RA packet.
RA SA
1 bit 1 bit
Remaining Time Restarting Neighbor System ID
2 bytes
6 bytes
Timers
Three timers are introduced to enhance IS-IS GR. They are T1, T2, and T3 timers.
11 Layer 3 Features
T1 Any interface enabled with IS-IS GR maintains a T1 timer. On a Level-1-2 router, broadcast interfaces maintain a T1 timer for Level-1 and Level-2 neighbor relationships respectively. If the GR restarter has already sent an IIH packet with RR being set but does not receive any IIH packet that carries the restart TLV and the RA set from the GR helper even after the T1 timer expires, the GR restarter will reset the T1 timer and continues to send the restart TLV. If the ACK packet is received or the T1 timer expires for three times, the T1 timer is deleted. The default value of a T1 timer is 3 seconds.
T2 Level-1 and Level-2 LSDBs maintain separate T2 timers. T2 is the maximum time that the system waits for the synchronization of various LSDBs. T2 is generally 60 seconds.
T3 The entire system maintains a T3 timer. T3 timer can be considered as the maximum time for GR to complete. If the T3 timer expires, GR fails. The initial value of the T3 timer is 65535 seconds. After the IIH packets that carry the RA are received from neighbors, the value of the T3 timer becomes the smallest value of the Remaining Time field among the Remaining Time fields of the IIH packets. The T3 timer applies to only restarting devices.
Session Mechanism of IS-IS GR

For differentiation, GR triggered by the master/slave switchover or the restart of an IS-IS process is referred to as restarting. In this case, the FIB table remains unchanged. GR triggered by router restart is referred to as starting. In this case, the FIB table is updated. The following describes the process of IS-IS GR in restarting and starting modes:
IS-IS Restarting
Figure 11-39 shows the process of IS-IS restarting.
Issue 01 (2011-10-30)
312
11 Layer 3 Features
Figure 11-39 Process of IS-IS restarting
GR Restarter
GR Helper
Active/standby switchover Start T1, T2, and T3 timers Reset T3 timer CSNP Delete T1 timer Delete T2 timer Delete T3 timer and Update the FIB table LSPs IIH (Restart TLV, RR=1, RA=0, SA=0)
IIH (Restart TLV, RR=0, RA=1, SA=0)
Flood LSPs
Update the FIB table
1.
After performing the protocol restart, the GR restarter performs the following actions: l Starts T1, T2, and T3 timers. l Sends IIH packets that contain the restart TLV from all interfaces. In such a packet, RR is set to 1, and RA and SA are set to 0.
2.
After receiving an IIH packet, the GR helper performs the following actions: l Maintains the neighbor relationship and refreshes the current Holdtime. l Replies an IIH packet containing the restart TLV. In the packet, RR is set to 0; RA is set to 1, and the value of the Remaining Time field indicates the period from the current moment to the timeout of the Holdtime. l Sends CSNPs and all LSPs to the GR restarter.
NOTE
l On a P2P link, a neighbor must send CSNPs. l On a LAN link, only the neighbor of the DIS sends CSNPs. If the DIS is restarted, a temporary DIS is elected from the other routers on the LAN.
If the GR helper does not support GR, it ignores the restart TLV and resets the adjacency with the GR restarter according to the normal processing of IS-IS. 3. After the GR restarter receives the IIH response packet, in which RR is set to 0 and RA is set to 1, from the neighbor, it performs the following actions: l Compares the current value of the T3 timer with the value of the Remaining Time field in the packet. The smaller one is taken as the value of the T3 timer.
Issue 01 (2011-10-30)
313
11 Layer 3 Features
l Deletes the T1 timer maintained by the interface that receives the ACK packet and CSNPs. l If the interface does not receive the ACK packet or CSNPs, the GR restarter constantly resets the T1 timer and resends the IIH packet that contains the restart TLV. If the number of the timeouts of the T1 timer exceeds the threshold value, the GR restarter forcibly deletes the T1 timer and turns to the normal IS-IS processing to complete LSDB synchronization. 4. After the GR restarter deletes the T1 timers on all interfaces, the synchronization with all neighbors is complete when the CSNP list is cleared and all LSPs are collected. The T2 timer is then deleted. After the T2 timer is deleted, the LSDB of the level has been synchronized. l In the case of a Level-1 or Level-2 router, the SPF caculation is triggered. l In the case of a Level-1-2 router, determine whether the T2 timer on the router of the other level is also deleted. If both the T2 timers are deleted, the SPF calculation is triggered. Otherwise, the router waits for the T2 timer of the other level to expire. 6. After all T2 timers are deleted, the GR restarter deletes the T3 timer and updates the FIB table. The GR restarter re-generates the LSPs of each level and floods them. During the LSDB synchronization, the GR restarter deletes the LSPs generated before GR. So far, the IS-IS restarting of the GR restarter is complete.
5.
7.
IS-IS Starting
The starting device does not keep the FIB table. Thus, the starting device hopes the neighbors, whose adjacency with itself is Up before it starts, reset their adjacency, and suppress the neighbors from advertising their adjacency. The IS-IS starting process is different from the ISIS restarting process, as shown in Figure 11-40.
Issue 01 (2011-10-30)
314
11 Layer 3 Features
Figure 11-40 Process of IS-IS starting
GR Restarter
GR Helper
Starting Start T2 timer for various LSPDBs Start T1 timer IIH (Restart TLV, RR=0, RA=0, SA=1) Reestablish the adjacency relationship IIH (Restart TLV, RR=1, RA=0, SA=1) IIH (Restart TLV, RR=0, RA=1, SA=0)
Delete T1 timer Delete T2 timer Update the FIB table
CSNP LSPs
Flood LSPs
Update the FIB table
1.
After the GR restarter is started, it performs the following actions: l Starts the T2 timer for the synchronization of LSDBs of each level. l Sends IIH packets that contain the restart TLV from all interfaces. In such a packet, RR is set to 0, and SA is set to 1. If RR is set to 0, a router is started. If SA is set to 1, the router requests its neighbor to suppress the advertisement of their adjacency before the neighbor receives the IIH packet in which SA is set to 0.
2.
After the neighbor receives the IIH packet that carries the restart TLV, it performs the following actions according to whether GR is supported: l GR is supported. Re-initiates the adjacency. Deletes the description of the adjacency with the GR restarter from the sent LSP. The neighbor also ignores the link connected to the GR restarter when performing SPF calculation until it receives an IIH packet in which SA is set to 0. l GR is not supported. Ignores the restart TLV and resets the adjacency with the GR restarter. Replies an IIH packet that does not contain the restart TLV. The neighbor then turns to the normal IS-IS processing. In this case, the neighbor does not suppress the
Issue 01 (2011-10-30)
315
11 Layer 3 Features
advertisement of the adjacency with the GR restarter. On a P2P link, the neighbor also sends a CSNP. 3. After the adjacency is re-initiated, the GR restarter re-establishes the adjacency with the neighbors on each interface. When an adjacency set on an interface is in the Up state, the GR restarter starts the T1 timer for the interface. After the T1 timer expires, the GR restarter sends an IIH packet in which both RR and SA are set to 1. After the neighbor receives the IIH packet, it replies an IIH packet in which RR is set to 0 and RA is set to 1 and sends a CSNP. After the GR restarter receives the IIH ACK packet and CSNP from the neighbor, it deletes the T1 timer. If the GR restarter does not receive the IIH packet or CSNP, it constantly resets the T1 timer and resends the IIH packet in which RR and SA are set to 1. If the number of the timeouts of the T1 timer exceeds the threshold value, the GR restarter forcibly deletes the T1 timer and turns to the normal IS-IS processing to complete LSDB synchronization. 7. 8. 9. After receiving the CSNP from the helper, the GR restarter synchronizes the LSDB. After the LSDB of this level is synchronized, the T2 timer is deleted. After all T2 timers are deleted, the SPF calculation is started and LSPs are regenerated and flooded.
4. 5. 6.
10. So far, the IS-IS starting of the GR restarter is complete.
GR is typically applied on PEs, especially single point PEs. In the scenario where a single point PE fails, or master/slave switchover occurs on a PE due to maintenance operations such as upgrading the software version, GR is configured to ensure non-stop forwarding of key services. Figure 11-41 shows the networking. Figure 11-41 Application of GR on the provider network
VPN A CE-1 PE1 PE3
VPN B CE-2
IS-IS Level-2
PE4 VPN B CE-4
VPN A CE-3 PE2
IBGP Full mesh
AS#100
Issue 01 (2011-10-30)
316
11 Layer 3 Features
NOTE
NSF is deployed on PE2 to prevent single-node failure on PE2; IS-IS GR, BGP GR, and LDP GR run on PE2.
On the PEs, IS-IS, BGP, or LDP GR is run. On the Ps, IS-IS or LDP GR is run. The MPU/SRUs on the PEs and Ps work in backup mode.
11.7.8.15 IS-IS Wide Metric

As defined in RFC 3784, the value of an interface metric can be extended to 16777215, and the metric of a route can reach 4261412864. On large-scale networks, a small range of metrics cannot meet the requirements. Thus, wide metric is introduced. In the earlier ISO 10589, the greatest value of an interface metric can be only 63. TLV type 128 and TLV type 130 contain information about routes; TLV type 2 contains information about ISIS neighbors. After IS-IS wide metric is enabled, TLV type 135 contains information about routes; TLV type 22 contains information about IS-IS neighbors. l The following lists the TLVs used in narrow mode: IP Internal Reachability TLV: carries internal routes. IP External Reachability TLV: carries external routes. IS Neighbors TLV: carries information about neighbors. l The following lists the TLVs used in wide mode: Extended IP Reachability TLV: replaces the earlier IP reachability TLV and carries information about routes. This TLV expands the range of route cost to 4 bytes and carries sub-TLVs. IS Extended Neighbors TLV: carries information about neighbors.
NOTE
IS-IS in wide mode and IS-IS in narrow mode cannot communicate. If IS-IS in wide mode and IS-IS in narrow mode need to communicate, you must change the mode to enable all routers on the network to receive packets sent by other routers.
Table 11-18 List of modes of receiving and sending Mode\Receiving and Sending narrow narrow-compatible compatible wide-compatible wide Receiving narrow narrow&wide narrow&wide narrow&wide wide Sending narrow narrow narrow&wide wide wide
Issue 01 (2011-10-30)
317
11 Layer 3 Features
When the cost-style is set to compatible, IS-IS sends the information in narrow mode and in wide mode respectively.
Process
CAUTION
The change of cost-style causes the IS-IS process to be restarted. Thus, be cautious to use the cost-style command. l Changing the sending mode from narrow to wide The information used to be carried by TLV type 128, TLV type 130, and TLV type 2 is now carried by TLV type 135 and TLV type 22. l Changing the sending mode from wide to narrow The information used to be carried by TLV type 135 and TLV type 22 is now carried by TLV type 128, TLV type 130, and TLV type 2. l Changing the sending mode from narrow/wide to narrow&wide The information used to be carried in narrow/wide mode is now carried by TLV type 128, TLV type 130, TLV type 2, TLV type 135, and TLV type 22.
11.7.8.16 BFD for IS-IS

BFD functions as a simple "Hello" protocol. It is similar to the adjacency test of a routing protocol in many aspects. Two systems periodically send BFD packets on the path between them. If one system does not receive any BFD packet from its peer within the detection period, the system considers that the bidirectional path to its peer is faulty. Under some conditions, systems need to negotiate the sending and receiving rates to reduce the load. BFD is classified into static BFD and dynamic BFD.
NOTE
BFD uses the local discriminator and remote discriminator to differentiate multiple BFD sessions between the same pair of systems.
Static BFD In static BFD, BFD session parameters including local and remote discriminators are set through commands, and the requests for establishing BFD sessions are manually delivered.
Dynamic BFD(including BFD for IPv4) In dynamic BFD, the establishment of BFD sessions is triggered by routing protocols. The local discriminator is dynamically assigned, and the remote discriminator is learned by a routing protocol.
In BFD for IS-IS, the establishment of a BFD session is dynamically triggered by IS-IS instead of being performed manually. When detecting a fault, BFD notifies IS-IS of the fault through the RM module. IS-IS then sets the status of the associated neighbor relationship to Down, rapidly advertises the changed Link State PDU (LSP), and performs incremental SPF. In this manner, fast route convergence is implemented. Generally, the interval for sending Hello packets is set to 10s. The interval for advertising that a neighbor is Down, that is, the Holddown time for keeping the neighbor relationship, is three
11 Layer 3 Features
times the interval for sending Hello packets. If a router does not receive any Hello packet from its neighbor within the Holddown time, the router deletes the associated neighbor relationship. A router can detect a neighbor fault at only the second level. As a result, a large number of packets may be lost on a high-speed network. BFD, which can provide link fault detection of light load and high speed (in milliseconds), is introduced to solve the preceding problem. BFD can provide millisecond-level fault detection. BFD does not take the place of the Hello mechanism of IS-IS, but works with IS-IS to more quickly detect the faults that occur on neighboring devices or links, and instructs IS-IS to recalculate routes to correctly guide packet forwarding.
Static BFD
In static BFD, BFD session parameters including local and remote discriminators are set through commands, and the requests for establishing BFD sessions are manually delivered. In this mode, the creation and deletion of BFD sessions need to be triggered manually, which is inflexible. Moreover, manual configuration errors may occur, for example, the local discriminator and the remote discriminator are incorrectly configured, which causes the abnormal functioning of the BFD session.
Dynamic BFD
In dynamic BFD, the establishment of BFD sessions is triggered by routing protocols.The establishment of a BFD-for-IPv4 session is triggered by IS-IS when an IPv4 neighbor relationship is set up. When setting up a new neighbor relationship, IS-IS sends parameters of the neighbors and detection parameters (including source and destination IP addresses) to BFD. BFD then sets up a session according to the received parameters. Dynamic BFD is more flexible than static BFD. The RM module provides related services for the association with the BFD module for IS-IS. Through RM, IS-IS instructs BFD to set up or tear down BFD sessions by sending notification messages. In addition, BFD events are transmitted to IS-IS through RM.
Establishment and Deletion of BFD Sessions

l Conditions for setting up a BFD session Basic IS-IS functions are configured on each router and IS-IS is enabled on the interfaces of the routers. BFD is enabled on each router, and BFD for IPv4 is enabled on interfaces or processes of the routers. BFD for IPv4 is enabled on interfaces or processes, and the status of the neighboring router is Up (the DIS must be elected on a broadcast network). l Process of setting up a BFD session P2P network After the conditions for setting up a BFD session are satisfied, IS-IS instructs BFD through RM to directly set up a BFD session between neighbors. Broadcast network
11 Layer 3 Features
After the conditions for establishing BFD sessions are met, and the DIS is elected, ISIS instructs BFD through RM to establish a BFD session between the DIS and each router. No BFD session is established between non-DISs. On a broadcast network, the routers (including non-DIS routers) of the same level on the same network segment can set up neighbor relationships. In the implementation of IS-IS BFD, however, BFD sessions are set up between the DIS and non-DIS devices rather than between non-DISs. On a P2P network, BFD sessions are directly set up between neighbors. If a Level-1-2 neighbor relationship is set up between two routers on a link, IS-IS sets up two BFD sessions for the Level-1 neighbor and the Level-2 neighbor on a broadcast network, but sets up only one BFD session on a P2P network. l Conditions for tearing down a BFD session P2P network When a neighbor relationship set up on P2P interfaces by IS-IS is torn down (that is, the neighbor relationship is not in the Up state) or when the IP protocol type of a neighbor is deleted, IS-IS tears down the BFD session. Broadcast network When a neighbor relationship set up on P2P interfaces by IS-IS is torn down (that is, the neighbor relationship is not in the Up state)when the IP protocol type of a neighbor is deleted, or when the DIS is re-elected, IS-IS tears down the BFD session. When the configurations of a dynamically established BFD session are deleted or BFD for IS-IS is disabled on an interface, all BFD sessions to which neighbor relationships between devices or between devices and the DIS correspond on the interface are deleted. After dynamic BFD is globally disabled in an IS-IS process, the BFD sessions on all the interfaces in this IS-IS process are deleted.
NOTE
BFD detects only one-hop links between IS-IS neighbors, because IS-IS establishes only one-hop neighbor relationships.
Response to the Down event of a BFD session When detecting a link failure, BFD generates a Down event, and then notifies RM of the event. RM then instructs IS-IS to deletes the neighbor relationship. IS-IS recalculates routes to speed up route convergence on the entire network.After BFD for IPv4 informs IS-IS of the link failure, IS-IS changes only the IPv4 route. When a router and its neighbor are Level-1-2 routers, they set up two neighbor relationships, that is, the Level-1 neighbor relationship and the Level-2 neighbor relationship. Then, ISIS sets up two BFD sessions for the Level-1 neighbor relationship and the Level-2 neighbor relationship. In this case, the RM module deletes the neighbor relationship of a specific level.
Applicable Environment
CAUTION
BFD needs to be configured according to the actual network environment. If timer parameters are set improperly, network flapping may occur. BFD for IS-IS can fast sense link changes to implement route convergence.
11 Layer 3 Features
Figure 11-42 Networking diagram of BFD for IS-IS

Router A Switch Router B
Primary path Backup path
Router C
The configuration requirements are as follows: l l l Enable IS-IS on the routers, as shown in Figure 11-42. Enable BFD globally. Enable BFD for IS-IS on Router A and Router B.
Thus, when the link between Router A and Router B becomes faulty, BFD can fast detect the fault and then notify it to IS-IS. IS-IS then turns the neighbor relationship on the interface Down and deletes the IP protocol type to which the neighbor relationship corresponds, which triggers route calculation. In addition, IS-IS updates LSPs so that the neighbors such as Router C can receive updated LSPs from Router B. Fast convergence of IS-IS is thus implemented.
11.7.8.17 IS-IS Authentication

IS-IS authentication encrypts IS-IS packets by adding the authentication field to packets to ensure network security. When a local router receives IS-IS packets from a remote router, the local router discards the packets if finding that the authentication passwords do not match. This protects the local router. According to the types of packets, the authencation is classified into the following: l l l Area authentication It is configured in the IS-IS process view to authenticate Level-1 CSNPs, PSNPs, and LSPs. Routing domain authentication It is configured in the IS-IS process view to authenticate Level-2 CSNPS, PSNPs, and LSPs. Interface authentication It is configured in the interface view to authenticate Level-1 and Level-2 Hello packets. According to the authentication modes of packets, the authentication is classified into the following: l Plain text authentication It is a simple authentication mode in which passwords are directly added to packets. This imposes security threats. Thus, the MD5 authentication is introduced. l
Issue 01 (2011-10-30)
MD5 authentication
11 Layer 3 Features
In MD5 authentication, passwords are encrypted through the MD5 algorithm before they are added to packets. This improves the security of the passwords. l Keychain authentication In Keychain authentication, you can configure the key chain that changes with time to further improve network security. IS-IS provides a TLV to carry authentication information, with the type of the TLV specified as 10. l l l Type The ISO defines the type of the authentication packets as 10, with a length of 1 byte. Length It indicates the length of the authentication TLV, which is 1 byte. Value It indicates the contents of the authentication, including the authentication type and authenticated password, which ranges from 1 to 254, in bytes. The authentication type is 1 byte. Type 0 is reserved. Type 1 indicates plain text authentication. Type 54 indicates MD5 authentication. Type 255 is used for routing domain private authentication methods. The authentication password is saved in the following modes: l l l The authentication password for IIH packets are saved on interfaces. It is implemented as interface authentication. The authentication password for Level-1 LSPs and SNPs are saved in the IS-IS process. It is implemented as area authentication. The authentication password for Level-2 LSPs and SNPs are saved in the IS-IS process. It is implemented as routing domain authentication.
Interface authentication can be classified into the following: l l A router sends authentication packets with the authentication TLV and verifies the authentication information of the packets it receives. A router sends authentication packets with the authentication TLV but does not verify the authentication information of the packets it receives.
For the area authentication and routing domain authentication, you can set a router to authenticate SNPs and LSPs separately. l l A router sends LSPs and SNPs carrying the authentication TLV and verifies the authentication information of the LSPs and SNPs it receives. A router sends LSPs carrying the authentication TLV and verifies the authentication information of the LSPs it receives. The router sends SNPs carrying the authentication TLV but does not verify the authentication information of the SNPs it receives. A router sends LSPs carrying the authentication TLV and verifies the authentication information of the LSPs it receives. The router sends SNPs without the authentication TLV and does not verify the authentication information of the SNPs it receives.
Issue 01 (2011-10-30)
11 Layer 3 Features
A router sends LSPs and SNPs carrying the authentication TLV but does not verify the authentication information of the LSPs and SNPs it receives.
Figure 11-43 Networking for IS-IS authentication on a broadcast network
RouterA
RouterB
RouterC
RouterD
RouterE
The requirements are as follows: l l l IS-IS neighbor relationships can be set up between multiple routers on the same network only when interface authentication is configured in the same manner on all the routers. When multiple routers are in the same area, you must configure area authentication in the same manner on all the routers to ensure the synchronization of their Level-1 LSDBs. When Level-2 neighbor relationships are set up between multiple routers, you must configure routing domain authentication in the same manner on all the routers to ensure the synchronization of their Level-2 LSDBs.

Term s TLV Description Type-Length-Value TLV encoding features high efficiency and expansibility. It is also called CodeLength-Value (CLV). T indicates that different types can be defined through different values. L indicates the total length of the value field. V indicates the actual data of the TLV and is most important. TLV encoding features high expansibility. New TLVs can be added to support new features, which is flexible in describing information loaded in packets.
Issue 01 (2011-10-30)
323
11 Layer 3 Features
Term s LSP
Description Link State Protocol Data Unit It broadcasts link states in the area and contains all information about a router. The information includes IS-IS neighbors, IP address prefix, the ES it is connected to, and the area address. LSPs are classified into Level-1 LSPs and Level-2 LSPs. A router generates one Level-1 LSP and one Level-2 LSP with fragments included.
CSNP
Complete Sequence Numbers Protocol Data Unit It contains brief information about the local LSDB and is used to synchronize the LSDBs of neighbors. CSNPs are sent and resolved at different levels.
DIS Pseud onodes PE CE NSR
Designated Intermediate System A virtual node that is used to simulate a broadcast network. It is generated by the DIS and sets up neighbor relationships with all routers on the broadcast network. Provider Edge Customer Edge Non-Stop Routing
Abbreviations
Abbreviation IS-IS IGP LSP CSNP SNP DIS TLV SPF MI MT Local-MT URT MIGP GR Full Spelling Intermediate System-Intermediate System Interior Gateway Protocol Link State Protocol Data Unit Complete Sequence Numbers Protocol Data Unit Sequence Number PDU Designated Intermediate System Type-Length-Value Shortest Path First Multiple Instance Multi-topology Local Multicast-Topology Unicast Routing Table IGP Routing Table for Multicast Graceful Restart
Issue 01 (2011-10-30)
324
11 Layer 3 Features
Abbreviation BGP RM VPN BFD CSPF LSP SNMP MIB PE CE RIB
Full Spelling Border Gateway Protocol Routing Management Virtual Private Networks Bidirectional Forwarding Detection Constraint-based Shortest Path First Lable Switched Path Simple Network Management Protocol Management Information Base Provider Edge Customers Edge Routing Information Base
11.7.9 OSPF
Open Shortest Path First (OSPF) is an interior gateway protocol (IGP) based on the link state developed by the Internet Engineering Task Force (IETF). This topic provides introduction to this feature and describes the principle of this feature.
11.7.9.1 Introduction to OSPF Definition

The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force (IETF), is a link-state Interior Gateway Protocol (IGP). At present, OSPF Version 2, defined in RFC 2328, is intended for IPv4, and OSPF Version 3, defined in RFC 2740, is intended for IPv6. OSPF stated in this document refers to OSPFv2, unless otherwise stated.
Purpose
Before the emergence of OSPF, the Routing Information Protocol (RIP) is widely used on networks as an IGP. RIP is a routing protocol based on the distance vector algorithm. Due to its slow convergence, routing loops, and poor scalability, RIP is gradually replaced by OSPF. As a link-state protocol, OSPF can solve many problems encountered by RIP. Additionally, OSPF features have the following advantages: l
Issue 01 (2011-10-30)
Transmits packets in multicast mode to reduce load on the routers that do not run OSPF.
11 Layer 3 Features
l l l
Supports Classless Interdomain Routing (CIDR). Supports load balancing among equal-cost routes. Supports packet encryption.
With the preceding advantages, OSPF is widely accepted and used as an IGP.
l l l l When using SCUN, the MA5600T/MA5603T supports up to 5120 OSPF routes. When using SCUL, the MA5600T/MA5603T supports up to 1024 OSPF routes. When using SCUB, the MA5600T/MA5603T supports up to 5120 OSPF routes. The MA5600T/MA5603T is able to exchange OSPF route information with the user-side, cascading-side, and network-side devices.
11.7.9.3 References
The following table lists the references of this document. Document RFC 1587 Description This document describes a new optional type of OSPF areas, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a device. Remarks -
RFC 1765
This RFC is experimental and non-standard.
RFC 2328 RFC 2370
RFC 3137
This RFC is informational and non-standard.
Issue 01 (2011-10-30)
326
11 Layer 3 Features
Document RFC 3623
Description
Remarks
This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF device can stay on the forwarding path even as its OSPF software is restarted. This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings. This document describes how conventional hopby-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. -
RFC 3630
RFC 3682
This RFC is experimental and non-standard. -
RFC 3906
RFC 4576
RFC 4577
RFC 4750
11.7.9.4 Fundamentals of OSPF

OSPF has the following advantages: l l l l Divides an Autonomous System (AS) into one or multiple logical areas. Advertises routes by sending Link State Advertisements (LSAs). Synchronizes routing information by exchanging OSPF packets between routers in OSPF areas. Encapsulates OSPF packets in IP packets and then sends the packets in unicast mode or multicast mode.
Issue 01 (2011-10-30)
327
11 Layer 3 Features
OSPF Packet Type

Table 11-19 OSPF packet type Packet Hello packet Database Description (DD) packet Function Hello packets are sent periodically to discover and maintain OSPF neighbor relationships. DD packets carry brief information about the local Link State Database (LSDB) and are used to synchronize the LSDBs of two routers. LSR packets are used to request the required LSAs from neighbors. LSR packets are sent only after DD packets are exchanged successfully. Link State Update (LSU) packet Link State Acknowledgment (LSAck) packet LSU packets are used to send the required LSAs to neighbors. LSAck packets are used to acknowledge the received LSAs.
Link State Request (LSR) packet
LSA Type
Table 11-20 OSPF LSA type LSA Router-LSA (Type1) Function Describes the link status and link cost of a MA5600T/ MA5603T. It is generated by each MA5600T/MA5603T and advertised in the area to which the MA5600T/MA5603T belongs. Describes the link status of all routers in the local network segment. It is generated by a designated router (DR) and advertised in the area to which the DR belongs. Describe the routes in a network segment and advertise the routes to the related non totally STUB or NSSA area. Describes routes to an Autonomous System Boundary Router (ASBR). It is generated by an ABR and advertised in the related areas except the area to which the ASBR belongs. Describes routes to a destination outside the AS. It is generated by an ASBR and advertised in all areas except stub areas and Not-So-Stubby Areas (NSSAs). Describes routes to a destination outside the AS. It is generated by an ASBR and advertised in NSSAs only.
Network-LSA (Type2)
Network-summary-LSA (Type3) ASBR-summary-LSA (Type4) AS-external-LSA (Type5)
NSSA-LSA (Type7)
Issue 01 (2011-10-30)
328
11 Layer 3 Features
LSA Opaque-LSA (Type9/ Type10/Type11)
Function Provides a general mechanism for OSPF extension: l Type9 LSAs are advertised in the network segment where interfaces reside. Grace LSAs used to support GR are one type of Type9 LSAs. l Type10 LSAs are advertised in an area. LSAs used to support TE are one type of Type10 LSAs. l Type11 LSAs are advertised in an AS. At present, there are no application examples of Type11 LSAs.
Router Type
Figure 11-44 lists the types of common routers in OSPF. Figure 11-44 Router type
IS-IS
ASBR
Area1 Internal Router Area0
Area4 Backbone Router
Area2
ABR
Area3
Table 11-21 OSPF router type Router Internal router Area Border Router (ABR) Description All interfaces of an internal router belong to the same OSPF area. An ABR can belong to two or more areas, and one of the areas must be a backbone area. An ABR is used to connect the backbone area and nonbackbone areas. It can be physically or logically connected to the backbone area.
Issue 01 (2011-10-30)
329
11 Layer 3 Features
Router Backbone router
Description At least one interface on a backbone router belongs to the backbone area. All ABRs and internal routers in Area 0, therefore, are backbone routers.
AS Boundary Router (ASBR)
An ASBR exchanges routing information with other ASs. An ASBR may not reside at the boundary of an AS. It can be an internal router or an ABR. If an OSPF router imports external routes, the router is an ASBR.
OSPF Route Type

Inter-area routes and intra-area routes describe the network structure of an AS. External routes describe how to select a route to a destination outside an AS. OSPF classifies the imported AS external routes into Type1 and Type2 external routes. Table 11-22 lists route types in descending order of priority. Table 11-22 OSPF route type Route Intra area Inter area Type1 external route Description Intra-area routes Inter-area routes Because of the high reliability of Type1 external routes, the calculated cost of external routes equals that of AS internal routes, and can be compared with the cost of OSPF routes. That is, the cost of a Type1 external route equals the cost of the route from the router to the corresponding ASBR plus the cost of the route from the ASBR to the destination. Type2 external route Because of the low reliability of Type2 external routes, their costs are considered greater than the cost of any internal path to an ASBR. Thus, the cost of a Type2 external route equals the cost of the route from the ASBR to the destination.
Area Type
Table 11-23 OSPF area type Area Totally stub area Function Allows the Type3 default routes advertised by an ABR, and denies the routes outside an AS and inter-area routes.
330
Issue 01 (2011-10-30)
11 Layer 3 Features
Area Stub area NSSA Totally NSSA
Function Allows inter-area routes, which is different from a totally stub area. Imports routes outside an AS, which is different from a stub area. An ASBR advertises Type7 LSAs in the local area. Denies inter-area routes, which is different from an NSSA.
OSPF Network Type

According to link layer protocols, OSPF classifies networks into the following types, as shown in Table 11-24. Table 11-24 OSPF network type Network Broadcast Description If the link layer protocol is Ethernet or Fiber Distributed Data Interface (FDDI), OSPF defaults the network type to broadcast. In this type of networks, l Hello packets, LSU packets, and LSAck packets are transmitted in multicast mode. The address 224.0.0.5 is the reserved IP multicast address of the OSPF router, and the address 224.0.0.6 is the reserved IP multicast address of the OSPF DR. l DD packets and LSR packets are transmitted in unicast mode. Non-Broadcast Multiple Access (NBMA) If the link layer protocol is ATM, OSPF defaults the network type to NBMA. In this type of networks, protocol packets, such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets, are transmitted in unicast mode. Point-to-Multipoint (P2MP) Regardless of the link layer protocol, OSPF does not default the network type to P2MP. A P2MP network must be forcibly changed from other network types. The common practice is to change a non-fully connected NBMA network to a P2MP network. In this type of networks, l Hello packets are transmitted in multicast mode through the multicast address 224.0.0.5. l Other protocol packets, such as DD packets, LSR packets, LSU packets, and LSAck packets, are transmitted in unicast mode. Point-to-point (P2P) If the link layer protocol is PPP, HDLC, or LAPB, OSPF defaults the network type to P2P. In this type of networks, protocol packets, such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets, are transmitted in multicast mode through the multicast address 224.0.0.5.
11 Layer 3 Features
Stub Area
A stub area is a special area where ABRs do not flood the received external routes. In a stub area, the size of the routing table of routers and routing information in transmission are greatly reduced. Configuring a stub area is optional. Not all areas can be configured as stub areas. Generally, a stub area is a non-backbone area with only one ABR and is located at the AS boundary. To ensure the reachability of a destination outside an AS, the ABR in a stub area generates a default route and advertises it to non-ABRs in the stub area. Note the following when configuring a stub area: l l l l The backbone area cannot be configured as a stub area. If an area needs to be configured as a stub area, all the routers in this area must be configured with the stub command. An ASBR cannot exist in a stub area. That is, external routes are not flooded in the stub area. A virtual link cannot pass through a stub area.
OSPF Packet Authentication

OSPF supports packet authentication. Only the OSPF packets that pass the authentication can be received. If packets fail to pass the authentication, the neighbor relationship cannot be established. The MA5600T/MA5603T supports the following authentication modes: l l Area authentication mode Interface authentication mode
According to encryption algorithms, the authentication modes supported by the MA5600T/ MA5603T are classified into null, simple, MD5, and HMAC-MD5. When the area authentication mode and interface authentication mode are available, the interface authentication mode is preferred.
OSPF Route Aggregation

The routes with the same prefix can be aggregated into one route and the aggregated route is advertised in other areas. This is called route aggregation. After route aggregation, route information can be reduced. Consequently, the size of routing tables is reduced, which improves the performance of routers. Route aggregation can be carried out in the following manners: l ABR aggregation When an ABR transmits routing information to other areas, it originates Type3 LSAs per network segment. If some consecutive segments exist in this area, you can run the related command to aggregate these segments into one segment. An ABR sends only one
11 Layer 3 Features
aggregated LSA. Any LSA that belongs to the aggregated network segment specified by the command is not transmitted separately. l ASBR aggregation After route aggregation is enabled, if the local router is an ASBR, it aggregates the imported Type5 LSAs within the aggregated address range. After an NSSA area is configured, the ASBR aggregates the imported Type7 LSAs within the aggregated address range. If the local router is both an ABR and an ASBR, it aggregates Type5 LSAs that are transformed from Type7 LSAs.
OSPF Default Route

A default route refers to the route whose destination address and mask are all 0s. When a router does not have exact matching routes, it can forward packets through default routes. OSPF default routes are applicable to the following situations: l l An ABR advertises the default Type3 summary-LSAs to instruct intra-area routers to forward packets to other areas. An ASBR advertises default Type5 ASE LSAs or Type7 NSSA LSAs to instruct intra-AS routers to forward packets to other ASs.
The principles for advertising OSPF LSAs describing default routes are as follows: l l An OSPF router advertises an LSA that describes a default route only when an interface on the OSPF router is connected to a network outside an area. If an OSPF router has already advertised an LSA that describes a default route, the OSPF route no longer learns LSAs of the same type advertised by other routers. The OSPF router calculates routes by using an LSA describing a default route in an LSDB, but not an LSA of the same type advertised by another router. If the OSPF router needs to advertise an LSA describing a default route only with the help of another route, the route cannot be the one in the local routing domain, that is, not the one learned by the local OSPF process. The external default route guides forwarding outside the local OSPF routing domain but the next hop of the routes in the local OSPF routing domain are inside the local OSPF routing domain, failing to forward packets outside the local OSPF routing domain.
According to the hierarchical management of OSPF routes, the priority of the default Type3 routes is higher than that of the default Type5 or Type7 route. Table 11-25 shows the advertisement of default routes in different areas. Table 11-25 Principles for advertising area-specific default routes Area Type Common area Advertising Principles By default, no default route is generated in a common area, even if a default route exists in the common area. After a default route is generated by another process, the default route must be advertised in an entire OSPF AS. To help OSPF generate a default route, you need to run a command on an ASBR. After the configuration, a default ASE LSA (Type5 LSA) is generated and advertised in the entire OSPF AS.
11 Layer 3 Features
Area Type Stub area
Advertising Principles AS external routes in Type5 LSAs cannot be advertised in a stub area. Routers in the stub area have to learn AS external routes from an ABR. The ABR automatically generates a default summary-LSA (Type3 LSA) and advertises it in the entire stub area. Then, routers in the stub area obtain reachable AS external routes through the ABR.
Totally stub area
AS external routes in Type5 LSAs or inter-area routes in Type3 LSAs cannot be advertised in a totally stub area. Routers in the totally stub area have to learn AS external routes and the routes to other areas through an ABR. To help OSPF generate a default router, you need to configure a totally stub area. After the totally stub area is configured, an ABR automatically generates a default summary-LSA (Type3 LSA) and advertises it to the entire totally stub area. Then, routers in the totally stub area obtain reachable AS external routes and routes to other areas through the ABR.
Issue 01 (2011-10-30)
334
11 Layer 3 Features
Area Type NSSA area
Advertising Principles A small number of AS external routes that are obtained through the ASBR in the NSSA area can be imported to an NSSA area, but routes to other areas in ASE LSAs (Type5 LSAs) cannot be advertised in the NSSA area. Routers in the NSSA area obtain AS external routes only through the ASBR in the same NSSA. No default route is generated after an NSSA area is configured. After an NSSA area is configured, either of the following operations can be performed to help OSPF generate a default route: l To help obtain AS external routes through the ASBR in the NSSA area and other external routes through other areas, you need to configure the relevant command on the ABR. The ABR then generates a default NSSA LSA (Type7 LSA) and advertises it in the entire NSSA. In this manner, a small number of AS external routes can be obtained through the ASBR in the NSSA, and other routes to other areas can be obtained through the ABR in the NSSA area connected to ASBR in other areas. l To help OSPF obtain all external routes only through the ASBR in the NSSA area, you need to run commands on the ASBR. The ASBR then generates a default NSSA LSA (Type7 LSA) and advertises it to the entire NSSA. In this manner, all external routes can be received only through the ASBR in an NSSA. In the preceding operations, the same command is run in different views. On an ABR, a Type7 LSA describing a default route is generated regardless of whether there is the route to 0.0.0.0 in the routing table. On an ASBR, a Type7 LSA describing a default route is generated only when there is the route to 0.0.0.0 in the routing table. The default route is flooded only in an NSSA area but not flooded in the entire OSPF area. If no route is found in the NSSA, the LSAs that are generated in the local NSSA area are sent out from the ASBR in the NSSA. LSAs of other OSPF areas, however, cannot be sent to other ASs through the ASBR. A Type7 LSA describing a default route is neither translated into a Type5 LSA describing a default route on an ABR nor advertised in the entire OSPF routing domain.
Totally NSSA area
External routes in ASE LSAs (Type5 LSAs) to other areas or interarea routes in Type3 LSAs cannot be advertised in a totally NSSA area. Routers in the totally NSSA area learn routes to other areas from an ABR. You can configure a totally NSSA area so that an ABR automatically generates a default Type3 LSA and advertises it to the entire totally NSSA. In this manner, routes to external areas and interarea routes can be advertised in the totally NSSA area through the ABR.
OSPF Route Filtering

OSPF supports the filtering of routes through routing policies. By default, OSPF does not filter routes.
11 Layer 3 Features
Routing policies used by OSPF include the routing policy, ACL, and IP prefix list. For details, refer to RM Feature Description. OSPF route filtering is applicable to the following situations: l Import of routes OSPF imports the routes that are learnt by other protocols. When OSPF imports routes, you can filter the routes by configuring routing policies so that OSPF imports only eligible routes. l Advertisement of imported routes OSPF advertises the imported routes to neighbors. Routing information to be advertised to neighbors can be filtered through the configured filtering rules. The filtering rules take effect only when being configured on ASBRs because only the ASBRs can import routes. l Learning of routes Filtering rules can be configured to enable OSPF to filter the received intra-area, inter-area, and AS external routes. The filtering action determines whether to add routing entries to the routing table. That is, only the routes that pass the filtering are added to the local routing table. All the routes, however, can still be advertised from the OSPF routing table. l Learning of inter-area LSAs ABRs can be configured to filter the incoming summary-LSAs of the local area through a command. This configuration takes effect only on ABRs because only the ABRs can advertise summary-LSAs. Table 11-26 Differences between inter-area LSA learning and route learning Inter-area LSA Learning Filters the incoming LSAs of an area directly. Route Learning Filters only the calculated routes in LSAs to determine whether these routes are added to the local routing table.
Advertisement of inter-area LSAs ABRs can be configured to filter the outgoing summary-LSAs of the local area through a command. This configuration takes effect only on ABRs.
OSPF Virtual Link

A virtual link refers to a logical channel established between two ABRs through a non-backbone area. l l A virtual link must be configured on both ends of the link; otherwise, it does not take effect. A transit area refers to the area that provides an internal route of a non-backbone area for both ends of the virtual link.
According to RFC 2328, during the deployment of OSPF, all the non-backbone areas need to be connected to the backbone area. Otherwise, some areas will be unreachable.
11 Layer 3 Features
As shown in Figure 11-45, Area 2 is not connected to the backbone area (Area 0), and Router A is not an ABR. Therefore, Router A does not advertise routing information of Network 1 in Area 0. As a result, Router B does not have the route to Network 1. Figure 11-45 Non-Backbone Area Not Connected to the Backbone Area
Network1 Area0 Area1 ABR RouterA
RouterB Area2
In actual applications, physical connectivity between non-backbone areas and backbone areas cannot be ensured because of various limitations. To solve this problem, you can configure OSPF virtual links. A virtual link is similar to a P2P connection between two ABRs. Similar to physical interfaces, the interfaces on both ends of the virtual link can be configured with parameters such as the interval for sending Hello packets. Figure 11-46 OSPF virtual link
Area0 ABR Virtual Link Area1 Transit Area ABR
Area2
As shown in Figure 11-46, OSPF packets transmitted between two ABRs are only forwarded by the OSPF routers that reside between the two ABRs. These routers detect that they are not the destinations of the packets, thus forwarding the packets as common IP packets.
OSPF Multi-process
OSPF supports multi-process. Multiple OSPF processes can run on the same router, and they are independent of each other. Route interaction between different OSPF processes is similar to route interaction between different routing protocols. An interface of a router belongs to only a certain OSPF process. A typical application of OSPF multi-process is to run OSPF between PEs and CEs in the VPN where OSPF is also adopted in the backbone network. On the PEs, the two OSPF processes are independent of each other.
11 Layer 3 Features
11.7.9.5 OSPF GR
Routers generally operate with the separation of the control plane and forwarding plane. When the network topology remains stable, the restart of the control plane does not affect the forwarding plane, and the forwarding plane can still forward data properly. This ensures nonstop service forwarding. In graceful restart (GR) mode, the forwarding plane continues to direct data forwarding once a restart occurs, and the actions on the control plane, such as the re-establishment of neighbor relationships and route calculation, do not affect the forwarding plane. In this manner, service interruption caused by route flapping is prevented so that the network reliability is improved.
Basic Concepts
GR is a technology used to ensure normal traffic forwarding and non-stop forwarding of key services during the restart of routing protocols. Unless otherwise stated, GR described in this section refers to the GR technology defined in RFC 3623. GR is one of high availability (HA) technologies, which comprise a set of comprehensive technologies, such as fault-tolerant redundancy, link protection, faulty node recovery, and traffic engineering. As a fault-tolerant redundancy technology, GR is widely used to ensure non-stop forwarding of key services during master/slave switchover and system upgrade. Concepts involved are as follows: l Grace-LSA OSPF supports GR by flooding grace LSAs. Grace LSAs are used to inform the neighbor of the GR time, cause, and interface address when GR starts and ends. l Role of a router during GR Restarter: indicates the router that restarts. The Restarter can be configured to support totally GR or partly GR. Helper: refers to the router that helps the Restarter. The Helper can be configured to support planned GR or unplanned GR or selectively support GR through the configured policies. l Cause of GR Unknown: indicates that GR is triggered by an unknown reason. Software restart: indicates that GR is triggered by commands. Software reload/upgrade: indicates that GR is triggered by software restart or upgrade. Switch to redundant control processor: indicates that GR is triggered by the abnormal master/slave switchover. l GR period The GR period cannot exceed 1800 seconds. OSPF routers can exit from GR regardless of whether GR succeeds or fails, without waiting for GR to expire.
Classification of GR
l Totally GR: indicates that when a neighbor of a router does not support GR, the router exits from GR.
Issue 01 (2011-10-30)
11 Layer 3 Features
l l
Partly GR: indicates that when a neighbor does not support GR, only the interface associated with this neighbor exits from GR, whereas the other interfaces perform GR normally. Planned GR: indicates that a router restarts or performs the master/slave switchover by using the command. The Restarter sends a grace LSA before restart or master/slave switchover. Unplanned GR: indicates that a router restarts or performs the master/slave switchover because of faults. A router directly performs the master/slave switchover, without sending a grace LSA, and then enters GR after the slave board goes Up. The process of unplanned GR is the same as that of planned GR.
GR Process
l A router starts GR. In planned GR mode, after the master/slave switchover is triggered through a command, the Restarter sends a grace LSA to all neighbors to inform them of the start, period, and cause of GR, and then performs the master/slave switchover. In unplanned GR, the Restarter does not send the grace LSA. In unplanned GR mode, the Restarter sends a grace LSA immediately after the slave board goes Up, informing neighbors of the start, period, and cause of GR. The Restarter then sends a grace LSA to each neighbor for five consecutive times. This ensures that neighbors receive the grace LSA. This operation is proposed by manufacturers but not defined by the OSPF protocol. The Restarter sends a grace LSA to notify neighbors that it enters GR. During GR, neighbors keep neighbor relationships with the Restarter so that other routers cannot detect the switchover of the Restarter. l GR process
Figure 11-47 OSPF GR process
RouterA
RouterB
Restarter Before the active/ standby switchover Switchover Finish switchover
Helper Grace-LSA LSAck Enter Helper
Return LSAck packet for the received LSA Grace-LSA Updates the GR Enter GR period for the Grace-LSAs received Send Hello packets, negotiate, Grace-LSAs exchange DD packets, and synchronize LSDB Full Flush Grace-LSA Exit the Helper successfully and generate Router-LSA
Exit GR successfully, calculate routes, and generate LSA
Issue 01 (2011-10-30)
339
11 Layer 3 Features
The router exits from GR. Table 11-27 Cause that a router exits from GR Executi on of GR GR succeed s. Restarter Helper
Before GR expires, the Restarter reestablishes neighbor relationships with all the neighbors before the master/slave switchover.
After the Helper receives the grace LSA with the Age being 3600s from the Restarter, the neighbor relationship between the Helper and Restarter enters the Full state. l The Helper does not receive the grace LSA from the Restarter before the neighbor relationship expires. l The status of the interface that functions as the Helper changes. l The Helper receives the LSA that is inconsistent with the LSA in the local LSDB from another router. This situation can be excluded after the Helper is configured not to perform strict LSA check. l The Helper receives the grace LSAs from two routers on the same network segment at the same time. l Neighbor relationships between the Helper and other neighbors change.
GR fails.
l GR expires, and neighbor relationships do not recover completely. l The router LSA or network LSA sent by the Helper causes the Restarter to fail to perform bidirectional check. l The status of the interface that functions as the Restarter changes. l The Restarter receives the 1-way Hello packet from the Helper. l The Restarter receives the grace LSA that is generated by another router on the same network segment. On the same network segment, only one router can perform GR. l On the same network segment, neighbors of the Restarter have different DRs or BDRs because the topology changes.
Issue 01 (2011-10-30)
340
11 Layer 3 Features
Comparison between the GR Mode and Non-GR Mode

Table 11-28 Comparison between the GR mode and non-GR mode Master/slave Switchover in Non-GR Mode l OSPF neighbor relationships are reestablished. l Routes are recalculated. l The forwarding table changes. l The entire network detects route changes, and route flapping occurs for a short period of time. l Packets are lost during forwarding, and services are interrupted. Master/slave Switchover in GR Mode l OSPF neighbor relationships are reestablished. l Routes are recalculated. l The forwarding table remains unchanged. l Except the neighbors of the device where the master/slave switchover occurs, other routers do not detect route changes. l No packets are lost during forwarding, and services are not affected.
11.7.9.6 OSPF NSSA Definition

OSPF Not-So-Stubby Areas (NSSAs) are a new type of OSPF areas. Derived from stub areas, NSSAs resemble stub areas in many ways. The difference between NSSAs and stub areas is that NSSAs can import and flood AS external routes to the entire OSPF AS, without learning external routes in other areas of the OSPF network.
Purpose
As defined in OSPF, stub areas cannot import external routes. This prevents a large number of external routes from consuming the bandwidth and storage resources of the Router s in stub areas. Stub areas thus cannot meet the requirement of the scenario where external routes need to be imported and resource consumption caused by external routes also needs to be avoided. Therefore, NSSAs are introduced. Figure 11-48 NSSA
RIP Type5 Type5 Area2 Type5 Type5 Area0 NSSA Area Type7 Area1
RIP
ASBR
ABR
ABR
ASBR
Issue 01 (2011-10-30)
341
11 Layer 3 Features
Type7 LSA
l l l l Type7 LSAs are a new type of LSAs that are introduced to support NSSAs and describe the imported external routes. Type7 LSAs are generated by the ASBRs of NSSAs and flooded only in the NSSAs where ASBRs reside. When receiving Type7 LSAs, the ABRs of NSSAs selectively translate the Type7 LSAs to Type5 LSAs so that external routes can be advertised in other areas of the OSPF network. Default routes can also be expressed through Type7 LSAs so that traffic can be forwarded to other ASs.
N-bit
Router s in an area must be configured with the same area type. In OSPF, the N-bit is carried in a Hello packet to identify that a Router supports NSSAs. OSPF neighbor relationships cannot be established between the Router s with different area types. Disobeying RFC 1587, some manufacturers also set the N-bit in OSPF Database Description (DD) packets. Huawei devices can be configured to be compatible with the devices of these manufacturers for interworking.
Translating Type7 LSAs to Type5 LSAs

To advertise the external routes imported by NSSAs in other areas, you need to translate Type7 LSAs to Type5 LSAs so that the external routes can be advertised in the entire OSPF network. l l l The Propagate bit (P-bit) informs a Router whether Type7 LSAs need to be translated. The ABR with the largest Router ID in an NSSA translates Type7 LSAs to Type5 LSAs. Only the Type7 LSAs with the set P-bit and forwarding address not being 0 are translated to Type5 LSAs. A forwarding address indicates that the packet to a specific destination address is to be forwarded to the address specified by the forwarding address. The default Type7 LSAs meeting the preceding conditions can also be translated. The Type7 LSAs generated by ABRs are not set with the P-bit.
l l
Preventing Loops Caused by Default Routes

There may be multiple ABRs in an NSSA. To prevent routing loops, ABRs do not calculate the default routes advertised by the peer.
11.7.9.7 BFD for OSPF Definition

Bidirectional Forwarding Detection (BFD) is a mechanism to detect communication faults between forwarding engines. To be specific, BFD detects connectivity of a data protocol on the same path between two systems. The path can be a physical link, a logical link, or a tunnel. In BFD for OSPF, a BFD session is associated with OSPF. The BFD session fast detects a link fault and then notifies OSPF of the fault. This speeds up OSPF's response to the change of the network topology.
11 Layer 3 Features
Purpose
The link fault or the topology change may cause Routers to recalculate routes. Therefore, the convergence of routing protocols must be sped up to improve the network performance. Link faults are unavoidable. Therefore, a feasible solution is required to detect faults faster and notify the faults to routing protocols immediately. If BFD is associated with routing protocols, once a link fault occurs, BFD can speed up the convergence of routing protocols. Table 11-29 BFD for OSPF Associated with BFD or Not Not associated with BFD Associated with BFD Link Fault Detection Mechanism Convergence Speed At the second level At the millisecond level
An OSPF Dead timer expires. By default, the timeout period of the timer is 40s. A BFD session goes Down.
Principle
Figure 11-49 BFD for OSPF
RouterA GE2/0/0 cost=1 RouterB
RouterC
The principle of BFD for OSPF is shown in Figure 11-49. 1. 2. 3. 4. OSPF neighbor relationships are established between these three Routers. After a neighbor relationship becomes Full, this triggers BFD to establish a BFD session. The outbound interface on Router A connected to Router B is GE 2. If the link fails, BFD detects the fault and then notifies Router A of the fault. Router A processes the event that a neighbor relationship becomes Down and re-calculates routes. After calculation, the outbound interface is GE 1 passes through Router C and then reaches Router B.
Issue 01 (2011-10-30)
co st =1 0
GE1/0/0
co st =1
343
11 Layer 3 Features
11.7.9.8 OSPF Smart-discover Definition

Generally, routers periodically send Hello packets through OSPF interfaces. That is, a router sends a Hello packet at the Hello interval by using a Hello timer. Sending Hello packets at a fixed interval slows down the establishment of OSPF neighbor relationships. Enabling Smart-discover can speed up the establishment of OSPF neighbor relationships in specific scenarios. Table 11-30 OSPF Smart-discover Smart-discover Is Configured or Not Smart-discover Is Not Configured Processing l Hello packets are sent only when the Hello timer expires. l A Hello packet is sent at the Hello interval. l Neighbors keep waiting to receive Hello packets within the timeout period. Smart-discover Is Configured l Hello packets are sent directly regardless of whether the Hello timer expires. l Neighbors can receive packets rapidly and perform status transition fast.
Principle
In the following scenarios, the interface enabled with Smart-discover can send Hello packets to neighbors actively, without having to wait for the Hello timer to expire: l l The neighbor status becomes 2-way for the first time. The neighbor status changes from 2-way or a higher state to Init.
11.7.9.9 OSPF-BGP Association Definition

When a new router is deployed in the network or a router is restarted, network traffic may be lost during BGP convergence. This is because IGP convergence is faster than BGP convergence. This problem can be solved through the association between OSPF and BGP.
Purpose
If a backup link exists, during traffic switchback, BGP traffic is lost because BGP route convergence is slower than OSPF route convergence. As shown in Figure 11-50, Router A, Router B, Router C, and Router D run OSPF and establish IBGP connections. Router C is the backup device of Router B. When the network is stable, BGP and OSPF routes converge completely on the devices.
11 Layer 3 Features
Normally, traffic from Router A to 10.3.1.0/30 passes through Router B. When Router B is faulty, traffic is switched to Router C. After Router B recovers, traffic is switched back to Router B; however, packet loss occurs. When traffic is switched back to Router B, IGP route convergence is faster than BGP route convergence. Consequently, OSPF routes converge first, whereas BGP route convergence is not complete. As a result, Router B does not know how to reach 10.3.1.0/30. Therefore, when packets from Router A to 10.3.1.0/30 are sent to Router B, they are discarded by Router B because Router B has no route to 10.3.1.0/30. Figure 11-50 OSPF-BGP association
RouterC
10.1.2.2/30 10.1.4.1/30
AS 20 RouterF
10.3.1.2/30
10.1.2.1/30
10.1.4.2/30
10.3.1.1/30
RouterA AS 10 RouterD
10.1.1.1/30
EBGP
10.2.1.1/30
RouterE
10.2.1.2/30
10.1.3.2/30
10.1.1.2/30
10.1.3.1/30
RouterB
Principle
The router enabled with OSPF-BGP association remains to be a stub router within the set association period. That is, the link metric in the LSA advertised by the router is the maximum value of 65535. In this manner, the router instructs other OSPF routers not to use it as a transit router for data forwarding. In Figure 11-50, OSPF-BGP association is enabled on Router B. In this situation, before BGP route convergence is complete, Router A continues to forward traffic to the backup link Router C, without forwarding traffic to Router B, until BGP route convergence on Router B is complete.
11.7.9.10 OSPF Database Overflow Definition

OSPF requires that routers in the same area have the same Link State Database (LSDB). With the continuous increase in routes on the network, some routers fail to bear so much routing information because of limited system resources. This situation is called OSPF database overflow.
11 Layer 3 Features
Purpose
l Configuring stub areas or NSSAs can solve the problem that the continuous increase in routing information causes the exhaustion of system resources of routers. Nevertheless, configuring stub areas or NSSAs cannot solve the problem that the unexpected increase in dynamic routes causes the database overflow. Setting the maximum number of external LSAs in the LSDB can dynamically limit the LSDB capacity, thus avoiding the problem caused by the database overflow.
Principle
Setting the maximum number of non-default external routes on a router can avoid database overflow. All routers on the OSPF network must be set with the same upper limit. In this manner, if the number of external routes on a router reaches the upper limit, the router enters the Overflow state and starts an overflow timer so that the timer automatically exits from the overflow state after the timer expires. Table 11-31 OSPF database overflow Phase of the Overflow State Entering the overflow state Staying in the overflow state OSPF Processing A router deletes all the non-default routes generated by itself. l The router does not generate non-default routes. l The router discards the newly received non-default routes, and does not reply with an LSAck packet. l When the overflow timer expires, the router checks whether external routes still exceed the upper limit. If so, the router restarts the timer. If not, the router exits from the overflow state. Exiting from the overflow state l The router deletes the overflow timer. l The router generates non-default routes. l The router learns the newly received non-default routes, and replies with an LSAck packet. l The router prepares to enter the overflow state for the next time.
11.7.9.11 OSPF Fast Convergence

OSPF fast convergence is an extended feature of OSPF implemented to speed up the convergence of routes. It includes the following: l I-SPF Incremental SPF (I-SPF) recalculates only the routes of the changed nodes rather than all the nodes when the network topology changes. This speeds up the calculation of routes. l
Issue 01 (2011-10-30)
PRC
11 Layer 3 Features
Partial Route Calculation (PRC) calculates only the changed routes when the routes on the network change. l Intelligent timer An Open Shortest Path First (OSPF) intelligent timer can dynamically adjust its value according to the user's configuration and the interval at which an event is triggered such as the route calculation interval, which ensures rapid and stable operation of a network. The OSPF intelligent timer applies the exponential backoff technology so that the value of the timer can reach the millisecond level.
I-SPF (Incremental SPF)

In ISO 10589, the Dijkstra algorithm is adopted to calculate routes. When a node changes on the network, this algorithm is used to recalculate all routes. The calculation lasts a long time and consumes too many CPU resources, thus affecting the convergence speed. I-SPF improves this algorithm. Except for the first time, only changed nodes instead of all nodes are involved in calculation. The SPT generated at last is the same as that generated by the previous algorithm. This decreases the CPU usage and speeds up the network convergence.
PRC (Partial Route Calculation)

Similar to I-SPF, PRC calculates only the changed routes. PRC, however, does not calculate the shortest path. It updates the routes based on the SPT calculated by I-SPF. In route calculation, a leaf represents a route, and a node represents a router. The SPT change and leaf change cause the change of routing information, but the SPT change is irrelevant to the leaf change. PRC processes routing information based on SPT or leaf information. l l l l If the SPT changes, PRC processes the routing information of all leaves on a changed node. If the SPT does not change, PRC does not process the routing information on any node. If the leaf changes, RPC processes the routing information on the leaf only. If the leaf does not change, PRC does not process the routing information on any leaf.
For example, if OSPF is enabled on an interface of a node, the SPT calculated by I-SPF remains unchanged. In this case, PRC updates only the routes of this interface, thus consuming less CPU resources. PRC working with I-SPF further improves the convergence performance of the network. It is an improvement of the original SPF algorithm.
NOTE
In the implementation of device, only I-SPF and PRC are used to calculate OSPF routes.
OSPF Intelligent Timer

On an unstable network, routes are frequently calculated, which consumes a great number of CPU resources. In addition, LSPs that describe the unstable topology are generated and transmitted on the unstable network. Frequently processing such LSAs affects the rapid and stable operation of the entire network. The OSPF intelligent timer controls route calculation, LSA generation, and LSA receiving to speed up route convergence on the entire network. The OSPF intelligent timer speeds up route convergence in the following modes:
11 Layer 3 Features
On a network where routes are repeatedly calculated, the OSPF intelligent timer dynamically adjusts the route calculation according to the user's configuration and the exponential backoff technology. In this manner, the number of route calculation times and the CPU resource consumption are decreased. Routes are calculated after the network topology becomes table. On an unstable network, if a router generates or receives LSAs due to frequent topology changes, the OSPF intelligent timer can dynamically adjust its value. No LSA is generated or handled within an interval, which prevents invalid LSAs from being generated and advertised on the entire network.
By default, the OSPF intelligent timer is started and uses the default value.
11.7.9.12 OSPF Mesh-Group Definition

In the scenario where there are multiple concurrent links, OSPF mesh-group can be deployed to classify links into a mesh group. In this manner, OSPF floods LSAs to only a link selected from the mesh group. This prevents unnecessary burden on the system caused by repetitive flooding. By default, mesh-group is disabled.
Purpose
After receiving or generating an LSA, an OSPF process floods the LSA. When there are multiple concurrent links, OSPF floods the LSA to each link and sends Update messages. In this case, if there are 2000 concurrent links, OSPF floods each LSA for 2000 times. Only one flooding, however, is valid. The flooding for the other 1999 times is repetitive. To prevent burden on the system caused by repetitive flooding, you can enable mesh-group to classify concurrent links into a mesh group and then select a primary link for flooding.
Principles
When multiple concurrent links exist between a router and its neighbor, you can enable OSPF mesh-group to reduce the burden on the links. As shown in Figure 11-51, Router A and Router B, which are connected through three links, establish an OSPF neighbor relationship. After receiving a new LSA from interface 4, Router A floods the LSA to Router B through interfaces 1, 2, and 3. This causes a heavy load on the concurrent links. For the neighbor with concurrent links, only a primary link is selected to flood the LSA. Figure 11-51 Flooding of LSAs when OSPF mesh-group is disabled
1 LSA 4 2 3 LSA
LSA
RouterA
LSA
RouterB
Issue 01 (2011-10-30)
348
11 Layer 3 Features
When multiple concurrent links exist between the devices enabled with OSPF mesh-group and neighbors, the device selects one primary link to flood the received LSAs, as shown in Figure 11-52. As defined in OSPF, LSAs can be flooded to a link only when the neighbor status is not lower than Exchange. In this case, when the status of the interface on the primary link is lower than Exchange, OSPF reselects a primary link from the concurrent links and then floods the LSA. After receiving the LSA flooded by Router A from link 1, Router B no longer floods the LSA to Router A through interfaces 2 and 3. Figure 11-52 Flooding of LSAs when OSPF mesh-group is enabled
1 LSA 4 2 3 LSA LSA
LSA
RouterA
RouterB
As defined by mesh-group, the Router ID of a neighbor uniquely identifies a mesh group. The interfaces connected to the same neighbor and with the status greater than Exchange, belong to the same mesh group. As shown in Figure 11-53, a mesh group of Router A resides in Area 0, which contains the links of interface 1 and interface 2. There is more than one neighbor of interface 3 that resides on the broadcast link. Therefore, interface 3 cannot join the mesh group. Figure 11-53 Interfaces failing to be added to a mesh group
1 4 2 3
RouterB
RouterA
Area0
NOTE
After a router is enabled with mesh-group, if the Router IDs of the router and its directly connected neighbor are the same, the LSDBs cannot be synchronized and routes cannot be calculated correctly. In this case, you need to reconfigure the Router ID of the neighbor. Note that it is incorrect to configure the Router ID of the neighbor the same as that of the router.
Issue 01 (2011-10-30)
349
11 Layer 3 Features
11.7.9.13 Priority-based OSPF Convergence

Priority-based OSPF convergence ensures that specific routes converge first in the case of a great number of routes. Different routes can be set with different convergence priorities. This allows important routes to converge first and thus improves network reliability. By using priority-based OSPF convergence, users can assign a high convergence priority to routes for key services so that those routes can converge fast. This decreases impact on key services.

Term PE CE Description Provider Edge: It is an edge router on an SP network, and is connected to the CE. PEs process all VPN services. Customer Edge: It is an edge router on the user network, and is connected to the PE. CEs cannot detect the connected VPN.
Abbreviations
Abbreviation OSPF GR LSA CSPF Full Spelling Open Shortest Path First Graceful Restart Link State Advertisement Constraint Shortest Path First
11.7.10 BGP
The Border Gateway Protocol (BGP) is an inter-AS dynamic routing protocol.
11.7.10.1 Introduction to BGP Definition

The Border Gateway Protocol (BGP) is a dynamic routing protocol used between autonomous systems (ASs). BGP-1 (defined in RFC 1105), BGP-2 (defined in RFC 1163), and BGP-3 (defined in RFC 1267) are three earlier-released versions of BGP. BGP exchanges the reachable inter-AS routes, establishes inter-AS paths, avoids routing loops, and applies routing policies between ASs. The current BGP version is BGP-4 defined by RFC 4271.
11 Layer 3 Features
As an exterior routing protocol on the Internet, BGP is widely used among Internet Service Providers (ISPs). BGP has the following characteristics: l Different from the Interior Gateway Protocol (IGP) such as Open Shortest Path First (OSPF) and Routing Information Protocol (RIP), BGP is an Exterior Gateway Protocol (EGP), which controls the route advertisement and selects the optimal route between ASs rather than discover and calculate routes. BGP uses the Transport Control Protocol (TCP) with the listening port number being 179 as the transport layer protocol. The reliability of BGP is thus enhanced. BGP selects inter-AS routes, which proposes high requirements on the reliability of the protocol. TCP with high reliability, therefore, is used to enhance the stability of BGP. BGP peers must be logically connected and establish TCP connections. The destination port number is 179 and the local port number is random. l l BGP supports Classless Inter-Domain Routing (CIDR). BGP transmits only the updated routes when routes are being updated. This reduces the bandwidth occupied by BGP for route distribution. Therefore, BGP is applicable to the Internet where a large number of routes are transmitted. BGP is a distance-vector routing protocol. BGP is designed to avoid loops. Inter-AS: BGP routes carry information about the ASs along the path. The routes that carry the local AS number are discarded, thus avoiding inter-AS loops. Intra-AS: BGP does not advertise the routes learned in the AS to the BGP peers, thus avoiding intra-AS loops. l l l BGP provides rich routing policies to flexibly select and filter routes. BGP provides the mechanism for preventing route flapping, which effectively enhances the stability of the Internet. BGP can be easily extended to adapt to the development of networks.
l l
Purpose
BGP transmits routes between ASs. It, however, is not required in all situations.
Issue 01 (2011-10-30)
351
11 Layer 3 Features
Figure 11-54 Application scenario of BGP

Client AS
IBGP EBGP EBGP
ISP1 Internet
ISP2
BGP is required in the following situations: l As shown in Figure 11-54, the user needs to be connected to two or more ISPs. The ISPs need to provide all or part of the Internet routes for the user. The Router , therefore, selects the optimal route through the AS of an ISP to the destination according to the AS_Path carried in BGP routes. Different organizations need to transmit the AS_Path.
BGP is not required in the following situations: l l l The user is connected to only one ISP. The ISP does not need to provide Internet routes for users. ASs are connected through default routes.
l IPV4: When using SCUN, the MA5600T/MA5603T supports up to 4096 BGP routes. When using SCUL, the MA5600T/MA5603T supports up to 1000 BGP routes. When using SCUF, the MA5600T/MA5603T supports up to 4096 BGP routes. When using SCUB, the MA5600T/MA5603T supports up to 2300 BGP routes. l The MA5600T/MA5603T supports one local AS.
11.7.10.3 References
Table 11-32 lists the references of this feature.
11 Layer 3 Features
Table 11-32 References Document RFC 4271 RFC 4760 RFC 3392 RFC 2918 RFC 2439 RFC 1997 RFC 4456 RFC 3065 RFC 3232 RFC 827 RFC 3682 RFC 4724 draft-rijsman-bfddown-subcode-00 RFC 4486 Description A Border Gateway Protocol 4 (BGP-4) Multiprotocol Extensions for BGP-4 Capabilities Advertisement with BGP-4 Route Refresh Capability for BGP-4 BGP Route Flap Damping BGP Communities Attribute BGP Route Reflection Autonomous System Confederations for BGP Assigned Numbers: RFC 1700 is Replaced by an On-line Database Exterior Gateway Protocol (EGP) The Generalized TTL Security Mechanism (GTSM) Graceful Restart Mechanism for BGP BFD Down Subcode for BGP Cease Notification Message Subcodes for BGP Cease Notification Message Remarks -
11.7.10.4 Basic Principle of BGP BGP Operating Modes

BGP operates on a Router in either of the following modes, as shown in Figure 11-55: l l Internal BGP (IBGP) External BGP (EBGP)
BGP is called IBGP when it runs within an AS; it is called EBGP when it runs between ASs.
Issue 01 (2011-10-30)
353
11 Layer 3 Features
Figure 11-55 BGP operating modes

Client AS
IBGP EBGP EBGP
ISP1 Internet
ISP2
Roles in Transmitting BGP Messages

l Speaker: The Router that sends BGP messages is called a BGP speaker. The speaker receives or generates new routing information, and then advertises the routing information to other BGP speakers. When receiving a new route from another AS, a BGP speaker compares the route with the current route. If the route takes precedence over the existing route, or the route is new, the speaker advertises this route to all other BGP speakers except the BGP speaker that sends this route. Peer: The BGP speakers that exchange messages with each other are called peers. Multiple peers compose a peer group.
BGP Messages
BGP runs by sending messages. There are five types of BGP messages, namely, the Open message, Update message, Notification message, Keepalive message, and Route-refresh message. l Open message: It is the first message that is sent after a TCP connection is set up, and is used to set up BGP peer relationships. After the peer receives an Open message and the peer negotiation succeeds, the peer sends a Keepalive message to confirm and maintain the peer relationship. Then, peers can exchange Update, Notification, Keepalive, and Routerefresh messages. Update message: It is used to exchange routes between BGP peers. The Update message can be used to advertise multiple reachable routes with the same attributes, or to withdraw multiple unreachable routes. An Update message can be used to advertise multiple reachable routes with the same attributes. These routes can share a group of route attributes. The route attributes
11 Layer 3 Features
contained in an Update message are applicable to all destination addresses (expressed by IP prefixes) contained in the Network Layer Reachability Information (NLRI) field of the Update message. An Update message can be used to withdraw multiple unreachable routes. Each route is identified by its destination address, which identifies the routes previously advertised between BGP speakers. An Update message can be used only to withdraw routes. In this case, it does not need to carry the path attributes or NLRI. On the contrary, an Update message can be used only to advertise the reachable routes, so it does not need to carry information about the withdrawn routes. l l l Notification message: When BGP detects an error, it sends a Notification message to its peer. The BGP connection is then torn down immediately. Keepalive message: BGP periodically sends a Keepalive message to the peer to maintain the peer relationship. Route-refresh message: It is used to notify the peer of the capability to refresh routes. If all Routers of BGP are enabled with the Route-refresh capability, the local BGP Router sends Route-refresh messages to peers when the import routing policy of BGP changes. After receiving the message, the peers resend their routing information to the local BGP Router. In this manner, the routing table of BGP can be dynamically refreshed and the new routing policy can be used, without tearing down BGP connections.
BGP Finite State Machine

The BGP Finite State Machine (FSM) has six states, namely, Idle, Connect, Active, OpenSent, OpenConfirm, and Established. l l l l l l In the Idle state, BGP denies all connection requests. This is the initial status of BGP. In the Connect state, BGP performs other actions after the TCP connection is set up In the Active state, BGP attempts to set up a TCP connection. This is the intermediate status of BGP. In the OpenSent state, BGP waits for the Open message from its peer. In the OpenConfirm state, BGP waits for a Notification message or a Keepalive message. In the Established state, BGP peers can exchange Update messages, Route-Refresh messages, Keepalive messages, and Notification messages.
During the establishment of BGP peer relationships, BGP is usually in the Idle, Active, or Established state. The BGP peer relationship can be established only when both the BGP peers are in the Established state. The two peers send Update messages to exchange routes.
BGP Processing
l BGP adopts TCP as its transport layer protocol. Therefore, before the BGP peer relationship is set up, a TCP connection must be set up between the peers. Then, BGP peers negotiate related parameters by exchanging Open messages, and finally establish the BGP peer relationship. After the peer relationship is set up, BGP peers exchange BGP routing tables. BGP does not periodically update the routing table. When BGP routes change, however, BGP updates the BGP routing table incrementally through Update messages.
Issue 01 (2011-10-30)
11 Layer 3 Features
BGP sends Keepalive messages to maintain the BGP connection between peers. When detecting an error on a network, for example, error packets or packets indicating unsupported negotiation capability are received, BGP sends a Notification message to report the error, and the BGP connection is torn down accordingly.
BGP Attributes
The BGP route attribute is a set of parameters that further describe routes. With the BGP route attribute, BGP can filter and select routes. All BGP route attributes are classified into the following types: l Well-known mandatory: It can be identified by all BGP Routers. This type of attribute is mandatory and must be carried in Update messages. Without this attribute, errors occur in the routing information. Well-known discretionary: It can be identified by all BGP Routers. The attribute is discretionary and is not necessarily carried in Update messages. Optional transitive: It indicates the transitive attribute between ASs. A BGP Router may not recognize this attribute, but it still receives these attributes and advertises them to other peers. Optional non-transitive: If a BGP Router does not recognize this attribute, the corresponding attributes are ignored and are not advertised to other peers.
l l
The following part describes the common BGP route attributes: l Origin The Origin attribute defines the origin of a route. It marks the paths of a BGP route. The Origin attribute is classified into the following types: Interior Gateway Protocol (IGP): It is of the highest priority. For the routing information obtained through an IGP of the AS that originates the route, the Origin attribute is IGP. For example, for the routes imported to the BGP routing table through the network command, the Origin attribute is IGP. Exterior Gateway Protocol (EGP): It is of the second highest priority. The Origin attribute of the routes obtained through EGP is EGP. Incomplete: It is of the lowest priority. The Origin attribute of the routes learned by other means is Incomplete. For example, for the routes imported through the importroute command by BGP, the Origin attribute is Incomplete. l AS_Path The AS_Path is used to record all ASs that a route passes through from the local end to the destination in the distance-vector (DV) order. Assume that the BGP speaker advertises a local route: When advertising the route to other ASs, the BGP speaker adds the local AS number in the AS_Path list, and advertises it to the neighboring Routers through Update messages. When advertising the route to the local AS, the BGP speaker creates an empty AS_Path list in an Update message. Assume that the BGP speaker advertises the routes learned from the Update messages of other BGP speakers: When advertising the route to other ASs, the BGP speaker adds the local AS number to the leftmost of the AS_Path list. According to the AS_Path attribute, the BGP Router that receives the route can know the ASs through which the route passes to the
11 Layer 3 Features
destination. The number of the AS that is nearest to the local AS is placed on the top of the list. The other AS numbers are arranged in sequence. When the BGP speaker advertises the route to the local AS, it does not change the AS_Path. l Next_Hop The Next_Hop attribute of BGP is different from that of IGP. It is not necessarily the IP address of a neighboring Router. Generally, the Next_Hop attribute complies with the following principles: When advertising a route to an EBGP peer, the BGP speaker sets the next hop of the route to be the address of the local interface through which the BGP peer relationship is set up. When advertising a locally generated route to an IBGP peer, the BGP speaker sets the next hop of the route to be the address of the local interface through which the BGP peer relationship is set up. When advertising a route learned from an EBGP peer to an IBGP peer, the BGP speaker does not change the next hop of the route. l MED The Multi-Exit-Discriminator (MED) is exchanged only between two neighboring ASs. The AS that receives the MED does not advertise it to any other ASs. The MED serves as the metric used by an IGP. It is used to determine the optimal route when traffic enters an AS. When a BGP Router obtains multiple routes to the same destination address but with different next hops through EBGP peers, the route with the smallest MED value is selected as the optimal route. l Local_Pref The Local_Pref attribute is exchanged only between IBGP peers and is not advertised to other ASs. It indicates preferences of the BGP Routers. The Local_Pref attribute is used to determine the optimal route when traffic leaves an AS. When a BGP Router obtains multiple routes to the same destination address but with different next hops through IBGP peers, the route with the largest Local_Pref value is selected.
Policies for BGP Route Selection

When there are multiple routes to the same destination, BGP selects routes according to the following policies: 1. 2. Prefers the route with the highest PreVal. PrefVal is a Huawei-specific parameter. It is valid only on the device where it is configured. Prefers the route with the highest Local_Pref. A route without Local_Pref is considered to have had the value set by using the default local-preference command or to have a value of 100 by default. 3. Prefers a locally originated route. A locally originated route takes precedence over a route learned from a peer. Locally originated routes include routes imported by using the network command or the import-route command, manually aggregated routes, and automatically summarized routes.
11 Layer 3 Features
(1) A summarized route is preferred. A summarized route takes precedence over a nonsummarized route. (2) A route obtained by using the aggregate command is preferred over a route obtained by using the summary automatic command. (3) A route imported by using the network command is preferred over a route imported by using the import-route command. 4. Prefers the route with the shortest AS_Path. l The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_Path length. l An AS_SET counts as 1, no matter how many ASs are in the set. l After the bestroute as-path-ignore command is run, the AS_Path attributes of routes are not compared in the route selection process. 5. 6. Prefers the route with the highest Origin type. IGP is higher than EGP, and EGP is higher than Incomplete. Prefers the route with the lowest Multi Exit Discriminator (MED). l The MEDs of only routes from the same AS but not a confederation sub-AS are compared. MEDs of two routes are compared only when the first AS number in the AS_SEQUENCE (excluding AS_CONFED_SEQUENCE) is the same for the two routes. l A route without any MED is assigned a MED of 0, unless the bestroute med-none-asmaximum command is run. If the bestroute med-none-as-maximum command is run, the route is assigned the highest MED of 4294967295. l After compare-different-as-med command is run, the MEDs in routes sent from peers in different ASs are compared. Do not use this command unless it is confirmed that different ASs use the same IGP and route selection mode. Otherwise, a loop may occur. l If the bestroute med-confederation command is run, MEDs are compared for routes that consist only of AS_CONFED_SEQUENCE. The first AS number in the AS_CONFED_SEQUENCE must be the same for the routes. l After the deterministic-med command is run, routes are not selected in the sequence in which routes are received. 7. Prefers EBGP routes over IBGP routes. EBGP is higher than IBGP, IBGP is higher than LocalCross, and LocalCross is higher than RemoteCross. If the ERT of a VPNv4 route in the routing table of a VPN instance on a PE matches the IRT of another VPN instance on the PE, the VPNv4 route will be added to the routing table of the second VPN instance. This is called LocalCross. If the ERT of a VPNv4 route from a remote PE is learned by the local PE and matches the IRT of a VPN instance on the local PE, the VPNv4 route will be added to the routing table of that VPN instance. This is called RemoteCross. 8. Prefers the route with the lowest IGP metric to the BGP next hop.
NOTE
Assume that load balancing is configured. If the preceding rules are the same and there are multiple external routes with the same AS_Path, load balancing will be performed based on the number of configured routes.
9.
Prefers the route with the shortest Cluster_List.
10. Prefers the route advertised by the Router with the smallest router ID.

NOTE
11 Layer 3 Features
If routes carry the Originator_ID, the originator ID is substituted for the router ID during route selection. The route with the smallest Originator_ID is preferred.
11. Prefers the route learned from the peer with the smallest address if the IP addresses of peers are compared in the route selection process.
Policies for BGP Route Advertisement

BGP adopts the following policies to advertise routes: l l l l l The BGP speaker advertises only the optimal route to its peer when there are multiple valid routes. The BGP speaker advertises the routes learned from EBGP Routers to all BGP peers, including EBGP peers and IBGP peers. The BGP speaker does not advertise the routes learned from IBGP Routers to its IBGP peers. The BGP speaker advertises the routes learned from IBGP Routers to its EBGP peers. The BGP speaker advertises all BGP routes to the new peers when the peer relationship is established.
Synchronization of IBGP and IGP

The synchronization of IBGP and IGP is to prevent misleading external AS Routers. If a non-BGP Router in an AS provides forwarding service, IP packets forwarded by this AS may be discarded because the destination address is unreachable. As shown in Figure 11-56, Router E learns a route 8.0.0.0/8 of Router A from Router D through BGP, and then forwards the packet to Router D. Router D searches the routing table and finds that the next hop is Router B. Router D forwards the packet to Router C through route iteration, because Router D learns a route to Router B through IGP. Router C, however, does not know the route to 8.0.0.0/8 and discards the packet. Figure 11-56 Synchronization of IBGP and IGP
8.0.0.0/8 AS20 RouterA AS10 RouterC IGP IBGP IGP RouterE EBGP AS30
EBGP
RouterB
RouterD
If the synchronization is configured, Routers check the IGP routing table before adding the IBGP route to the routing table and advertising it to the EBGP peers. The IBGP route is added to the routing table and advertised to the EBGP peers only when IGP knows this IBGP route. The synchronization can be disabled surely in the following cases: l
Issue 01 (2011-10-30)
The local AS is not a transitive AS (The AS20 in Figure 1 is a transitive AS).

11 Layer 3 Features
All Routers in the local AS are full-meshed IBGP peers.
11.7.10.5 Route Import

BGP itself cannot discover routes. Therefore, it needs to import other protocol routes, such as IGP or static routes to the BGP routing table. In this manner, these imported routes can be transmitted within an AS or between ASs. BGP can import routes either in Import mode or in Network mode. l In Import mode, BGP imports routes according to protocol types, for example, Routing Information Protocol (RIP) routes, Open Shortest Path First (OSPF) routes, Intermediate System-to-Intermediate System (IS-IS) routes, static routes, or direct routes. The Network mode is more precise than the Import mode. In Network mode, routes with the specified prefix and mask are imported to the BGP routing table.
11.7.10.6 Route Aggregation

In a large-scale network, the BGP routing table is rather large. You can configure route aggregation to reduce the size of the routing table. Route aggregation refers to the process of aggregating multiple routes into one route. After route aggregation, BGP advertises only the aggregated route rather than all specific routes to BGP peers. Two modes of BGP route aggregation are supported: l Automatic aggregation: aggregates the routes imported by BGP. After automatic aggregation is configured, BGP aggregates routes according to the natural network segment and sends only the aggregated route to the peers. For example, 10.1.1.1/24 and 10.2.1.1/24 are aggregated to 10.0.0.0/8, which is a Class A address. Manual aggregation: aggregates routes in the local BGP routing table. Manual aggregation can be used to control the attributes of the aggregated route and determine whether to advertise the specific routes.
IPv4 supports both automatic aggregation and manual aggregation.
11.7.10.7 Route Dampening

Route instability is reflected by route flapping. That is, a route in a routing table disappears and reappears frequently.
NOTE
A route is added to the routing table, and then is withdrawn. This process is called one route flapping.
When route flapping occurs, a device sends a routing update to the neighbors. The devices that receive the routing update need to recalculate routes and modify routing tables. Frequent route flapping consumes lots of bandwidths and CPU resources, and even affects the normal operation of a network. Route dampening solves the problem of route instability. In most situations, BGP is applied to complex networks where routes change frequently. To avoid the impact of frequent route flapping, BGP adopts route dampening to suppress unstable routes. BGP dampening measures the stability of a route by using a penalty value. The greater the penalty value, the more unstable the route. Each time route flapping occurs (route flapping refers to that
11 Layer 3 Features
a route changes from active to inactive), BGP adds a certain penalty value (1000) to this route. When the penalty value of a route exceeds the suppression threshold, the route is suppressed. As a result, BGP does not add the route to the routing table, or advertise any Update message to BGP peers. The penalty value of the suppressed route decreases to half after a certain period. This period is called half life. When the penalty value decreases to the reuse value, the route is reusable and is added to the routing table. At the same time, BGP advertises an Update message to BGP peers. The penalty value, suppression threshold, and half life can be manually configured. Figure 11-57 shows the process of BGP route dampening. Figure 11-57 Diagram of BGP route dampening
Penalty value
suppress value
reuse value suppress time time half-life
Route dampening applies only to EBGP routes. IBGP routes, however, cannot be dampened. Generally, IBGP routes contain the routes from the local AS, which require that the forwarding tables be the same. In addition, IGP fast convergence aims to achieve information synchronization. Therefore, if IBGP routes are dampened, dampening parameters vary on different devices, and thus the forwarding tables are inconsistent with each other.
11.7.10.8 Community Attribute

A community is a set of destination addresses with the same characteristics. It is expressed as a list in the unit of four bytes. In the device, the community is in the format of aa:nn or the community number. l aa:nn: The value of aa or nn ranges from 0 to 65535. The administrator can set a specific value as required. aa indicates the AS number and nn indicates the community identifier defined by the administrator. For example, if a route is from AS 100, and its community identifier defined by the administrator is 1, the format of the community is 100:1. Community number: It is an integer that ranges from 0 to 4294967295. As defined in RFC 1997, numbers from 0 (0x00000000) to 65535 (0x0000FFFF) and from 4294901760 (0xFFFF0000) to 4294967295 (0xFFFFFFFF) are reserved.
The community is used to simplify the application, maintenance, and management of routing policies. With the community, a group of BGP devices in multiple ASs can share the same
11 Layer 3 Features
routing policy. The community is a route attribute. It is transmitted between BGP peers and is not restricted by the AS. Before advertising a route with the community to peers, a BGP device can change the original community of this route. The peer group allows a group of peers to share the same policy while the community allows a group of BGP routes to share the same policy. Besides the well-known communities, you can use a community filter to filter self-defined extended communities to control routing policies in a more flexible manner.
Well-known Community
Table 11-33 lists the well-known communities of BGP routes. Table 11-33 Well-known communities of BGP routes Community Name Internet Community Identifier 0 (0x00000000) No_Export 4294967041 (0xFFFFFF01) Description By default, all routes belong to the Internet community. A route with this attribute can be advertised to all BGP peers. A route with this attribute cannot be advertised outside the local AS. If a confederation is defined, the route with this attributes cannot be advertised to the ASs outside the confederation, but to other sub-ASs in the confederation. A route with this attribute cannot be advertised to any other BGP peers. A route with this attribute cannot be advertised outside the local AS or to other sub-ASs in the confederation.
No_Advertise No_Export_Subconfed
4294967042 (0xFFFFFF02) 4294967043 (0xFFFFFF03)
Networking Applications
As shown in Figure 11-58, EBGP connections are established between Router B and Router A, and between Router B and Router C. With the community attribute of No_Export configured on Router A, the routes from AS10 advertised to AS20 are not advertised to other ASs by AS20.
Issue 01 (2011-10-30)
362
11 Layer 3 Features
Figure 11-58 Networking diagram of configuring BGP communities
AS 10
RouterA EBGP AS 20 EBGP AS 30 RouterC RouterB
11.7.10.9 BGP Confederation

The confederation is another method of dealing with increasing IBGP connections in an AS. It divides an AS into several sub-ASs. IBGP full meshes are established in each sub-AS, and EBGP full meshes are established between sub-ASs, as shown in Figure 11-59. Figure 11-59 Diagram of a confederation
RouterB AS 65002
RouterC AS 65003
AS 65001 RouterD
RouterF AS 100
RouterA
AS 200
RouterE
Issue 01 (2011-10-30)
363
11 Layer 3 Features
For BGP speakers outside the confederation (for example, the devices in AS100), the sub-ASs (AS65001, AS65002, and AS65003) in the same confederation are invisible. The external devices do not need to know the topology of each sub-AS. The confederation ID is the AS number that is used to identify the entire confederation. For example, AS 200 as shown in Figure 11-59 is the confederation ID. As shown in Figure 11-59, there are multiple BGP devices in AS200. To reduce IBGP connections, AS200 is divided into three sub-ASs, namely, AS65001, AS65002, and AS65003. In AS65001, IBGP full meshes are established between the three devices.
Applications and Limitations

The confederation needs to be configured on each device, and the device that joins the confederation must support the confederation function. The confederation has disadvantages. For example, if the devices originally are not in a confederation but later need to be configured as a confederation, the logical topology changes accordingly. In large-scale BGP networks, RR and confederation can be used together.
NOTE
The old speaker with 2-byte AS numbers and the new speaker with 4-byte AS numbers cannot exist in the same confederation. Otherwise, routing loops may occur because AS4_Path does not support confederations.
11.7.10.10 BGP GR
When BGP restarts, the peer relationship is re-established and the forwarding is interrupted. After Graceful Restart (GR) is enabled, traffic interruption can be avoided. The following roles are involved in the GR process: l GR restarter: indicates a device that performs GR caused by a fault or triggered by the administrator. The GR restarter must be a GR-capable device. That is, the router must be enabled with GR and negotiates the GR capability with its peer. GR helper: indicates a neighbor of the GR restarter. The GR helper must also have the GR capability.
The following concepts are involved in the GR process: l GR session: indicates the session with the GR capability. The GR session is a negotiation mechanism between the GR restarter and the GR helper. By controlling the session negotiation mechanism of the protocols, the GR restarter and the GR helper can know each other's GR capability and set up a GR session. GR time: indicates the time during which a GR helper retains the forwarding information after detecting that the GR restarter is Down. When detecting that the GR restarter is in the Down state, the GR helper retains the topology or routing information obtained from the GR restarter and does not delete the information during the GR time.
Principles of BGP GR are listed as follows: l Using the capability negotiation mechanism of BGP, BGP speakers negotiate the GR capability before setting up a BGP session with the GR capability.
Issue 01 (2011-10-30)
11 Layer 3 Features
When detecting the restart of the GR restarter, a GR helper does not delete the routing information and forwarding entries related to the GR restarter, but waits to re-establish a BGP connection with the GR restarter. After setting up a new BGP connection, the GR restarter and the GR helper update BGP routes.
In this manner, the forwarding is not interrupted. In addition, the flapping of BGP occurs only on the neighbors of the GR restarter, and does not occur in the entire routing domain. This is important for BGP that needs to process a large number of routes.
11.7.10.11 BGP Tracking

After BGP tracking is enabled on BGP peers, when a link between the BGP peers fails, one BGP peer can rapidly detect the unreachability of its neighbor, terminate the connection with the neighbor, and delete the routes received from the neighbor. Fast route convergence is thus implemented. The interval between when BGP detects the peer unreachable and when BGP terminates the associated connection needs to be configured properly to ensure network stability. l l If the interval is set to 0, BGP immediately terminates the connection between the local device and its peer after detecting the peer unreachable. If IGP route flapping occurs and the interval is set to 0, the peer relationship between the local device and its peer alternates between Up and Down. Therefore, the interval should be set to a value greater than the actual IGP route convergence time. When BGP neighbors successfully perform GR negotiation, active/standby switchover occurs on the BGP neighbors. To prevent the failure of GR, the interval should be set to a value greater than the GR convergence time. If the interval is set to be smaller than the GR convergence time, the connection between the local device and its BGP peer will be terminated, thus leading to the failure of GR.
BGP tracking can speed up network convergence and is easy to deploy. BGP route convergence on a network configured with BGP tracking, however, is slower than that on a network enabled with BFD. Therefore, BGP tracking cannot meet the requirements of voice services that require the high convergence speed.
Networking
As shown in Figure 11-60, Router A and Router C establish an IBGP neighbor relationship. BGP tracking is configured on Router A. Therefore, when the link between Router A and Router B fails, Router A can detect that Router C is unreachable after IGP fast route convergence and then terminates the BGP connection with Router C. Figure 11-60 Networking diagram of BGP tracking
RouterA
RouterB
RouterC
Issue 01 (2011-10-30)
365
11 Layer 3 Features
11.7.10.12 BGP Dynamic Update Peer-Groups

Currently, with the rapid increase in the size of the routing table and the complexity of the network topology, BGP is required to support more neighbors. Especially in the case of a large number of neighbors and routes, high-performance packaging and forwarding are required when a device needs to send routes to a large number of BGP neighbors, most of which share the same outbound policies. The dynamic update peer-groups feature treats all the BGP neighbors with the same outbound policies as an update-group. In this manner, each route to be sent is grouped once and then sent to all neighbors in the update-group, improving packaging efficiency exponentially. Without the dynamic update peer-groups feature, each route to be sent is grouped per neighbor. With the dynamic update peer-groups feature, routes are grouped uniformly and then sent separately. That is, each route to be sent is grouped once and then sent to all neighbors in the update-group, which improves grouping efficiency exponentially. When a large number of neighbors and routes exist, the BGP dynamic update peer-groups feature greatly improves the BGP route packaging and forwarding performance.
The application scenarios of the BGP dynamic update peer-groups feature are as follows: l l l International gateway RR Scenario where a device sends the routes received from EBGP neighbors to all IBGP neighbors
Issue 01 (2011-10-30)
366
11 Layer 3 Features
Figure 11-61 Networking for the international gateway
AS1000 AS200 AS65001
AS30 IGW Router

Internet Route
AS100 AS65002
AS120
Figure 11-62 Networking for the RR with many clients
AS100 RR1 RR2
IBGP
IBGP
Client
Client
Client
Client
Client
Client
Issue 01 (2011-10-30)
367
11 Layer 3 Features
Figure 11-63 Networking for a PE connecting multiple IBGP neighbors
AS200 RouterC
IBGP
AS100 RouterA
EBGP
RouterD
RouterB
IBGP
RouterE
RouterF
In the preceding scenarios, it is a common situation that a device needs to send routes to a large number of BGP neighbors, most of which share the same outbound policies. This situation is most obviously presented in the networking shown in Figure 11-62. When a large number of neighbors and routes exist, the forwarding efficiency is restricted. After the dynamic update peer-groups feature is applied, each route to be sent is grouped once and then sent to all neighbors in the update-group, improving packaging efficiency exponentially. For example, an RR has 100 clients and needs to reflect 100,000 routes to them. If the RR sends the routes grouped per neighbor to 100 clients, the total number of times that all routes are grouped is 100,000 x 100. After the dynamic update peer-groups feature is applied, the total number of grouping times changes to 100,000 x 1. In this manner, performance is improved by a factor of 100.
11.7.10.13 4-Byte AS Number

Currently, 2-byte AS numbers used on the network range from 0 to 65535. However, available AS numbers become almost exhausted. Therefore, 2-byte AS numbers need to be extended to 4-byte AS numbers, which should also be compatible with the old speaker that supports only 2byte AS numbers. The 4-byte AS number feature extends a 2-byte AS number to a 4-byte AS number, and negotiates the 4-byte AS number capability and transmits 4-byte AS numbers by defining a new capability code and new optional transitive attributes. This implements communications between new speakers that support 4-byte AS numbers, and between old speakers that support only 2byte AS numbers and new speakers. l l l l New speaker: indicates the peer that supports 4-byte AS numbers. Old speaker: indicates the peer that does not support 4-byte AS numbers. New session: indicates the BGP connection between new speakers. Old session: indicates the BGP connection between new speakers and old speakers, or between old speakers.
Issue 01 (2011-10-30)
368
11 Layer 3 Features
BGP Extension
To support 4-byte AS numbers, an open capability code 0x41 is defined for BGP connection negotiation. The capability code 0x41 indicates that the BGP speaker supports 4-byte AS numbers. Two new optional transitive attributes, AS4_Path with the attribute code being 0x11 and AS4_Aggregator with the attribute code being 0x12, are defined to transmit 4-byte AS numbers on old sessions. If a connection is set up between a new speaker and an old speaker and the AS number of the new speaker is greater than 65535, the remote AS number needs to be specified as AS_TRANS on the old speaker. AS_TRANS is a reserved AS number with the value being 23456.
Principles
When setting up connections, BGP neighbors determine whether the peer supports 4-byte AS numbers according to the optional capability field in Open messages. l l New sessions are set up between new speakers; therefore, AS_Path and Aggregator in an Update message carry 4-byte AS numbers. Old sessions are set up between new speakers and old speakers. AS_Path and Aggregator on old speakers carry 2-byte AS numbers. When a new speaker sends an Update message to an old speaker, if the AS number of the new speaker is greater than 65535, AS4_Path and AS4_Aggregator are used together with AS_Path and AS_Aggregator to carry 4-byte AS numbers. AS4_Path and AS4_Aggregator are transparent to the old speaker. When receiving messages containing AS_Path, AS4_Path, AS_Aggregator, and AS4_Aggregator from an old speaker, a new speaker reconstructs the actual AS_Path and AS_Aggregator based on the reconstruction algorithm.
As shown in Figure 11-64, there are old speakers that support 2-byte AS numbers and new speakers that support 4-byte AS numbers in the topology. The 4-byte AS number feature, together with AS4_Path, transmits routing information between old speakers and new speakers.
Issue 01 (2011-10-30)
369
11 Layer 3 Features
Figure 11-64 Networking for the application of 4-byte AS numbers
AS10
old speaker RouterA
D=(8.0.0.0) AS_Path (10)
AS20.1
new speaker RouterB
D=(8.0.0.0) AS_Path (23456, 10) AS4_Path (20.1, 10)
AS50.5
new speaker RouterC
D=(8.0.0.0) AS_Path (40.4, 30, 20.1, 10)
old speaker RouterD

D=(8.0.0.0) AS_Path (30, 23456, 10) AS4_Path (20.1, 10)
new speaker RouterE
AS30
AS40.4
As shown in Figure 11-64, before advertising route D=8.0.0.0 of AS 10 to other ASs, a BGP device performs the followings: 1. 2. BGP adds 10, the AS number of AS 10, to the AS_Path list (10). When the route passes AS 20.1, to enable Router D (old speaker) to transmit AS path information with 4-byte AS numbers, this route carries the AS4_Path attribute, that is, (20.1, 10). Router B then adds AS number 20.1 of the route to the leftmost of the AS_Path list, that is, (23456, 10). The value 23456 is obtained when AS_TRANS replaces 20.1. When the route passes AS 30, Router D, as an old speaker not aware of AS4_Path, transparently transmits AS4_Path (20.1, 10) to Router E. Router D then adds AS number 30 of the route to the leftmost of the AS_Path list, that is, (30, 23456, 10). When the route passes AS 40.4, after the reconstruction of AS_Path and AS4_Path, BGP adds 40.4, the AS number of AS 40.4, to the leftmost of the AS_Path list, that is, (40.4, 30, 20.1, 10). The rest may be deduced by analogy. After the device in AS 50.5 receives the route, the device learns the path to AS 10 according to the AS_Path list.
3.
4.
Issue 01 (2011-10-30)
370
11 Layer 3 Features

Term BGP Description BGP is a dynamic routing protocol used between ASs. Different from IGP protocols such as OSPF and RIP, BGP focuses on controlling route transmission and selecting optimal routes, rather than detect or calculate routes. Border Gateway Protocol fake-Autonomous System (BGP fake-AS) configures a fake autonomous system (AS) number for an External Border Gateway Protocol (EBGP) peer or an EBGP peer group to hide the real AS number of the peer or peer group. EBGP peers in other ASs only know the fake AS number of the EBGP peer or peer group. When a network shifts from its original AS to another AS, the fake-AS function allows peer configurations in the neighboring ASs to remain unchanged. This ensures smooth forwarding of BGP services.
Fake-AS
Abbreviations
Abbreviations BGP VPN RM AS ISP EGP IGP IBGP EBGP CE PE P NLRI CIDR RR RIB Full Spelling Border Gateway Protocol Virtual Private Network Routing Management Autonomous System Internet Service Provider Exterior Gateway Protocol Interior Gateway Protocol Internal BGP External BGP Customer Edge Provider Edge Provider Network Layer Reachability Information Classless Inter-Domain Routing Route Reflector Route Information Base
Issue 01 (2011-10-30)
371
11 Layer 3 Features
Abbreviations MP-BGP GR TTL
Full Spelling Multiprotocol Extensions for BGP Graceful Restart Time-To-Live
11.7.11 VRF
Virtual route forwarding instance (VRF) is a mechanism in which a device works as multiple virtual routing devices. After the Layer 3 interfaces of the device are divided into different VRFs, multiple route forwarding instances can be emulated on the device.
11.7.11.1 Introduction Definition

VRF is an Layer 3 virtual private network (L3VPN). VRF is a mechanism in which a device works as multiple virtual routing devices. After the Layer 3 interfaces of the device are divided into different VRFs, multiple route forwarding instances can be emulated on the device.
Purpose
Multiple virtual routing devices can be created on the MA5600T/MA5603T. That is, multiple L3VPNs can be established to implement the Layer 3 isolation and independent packet forwarding among different VRFs. Moreover, in different VRFs, the IP address can be reused, and also DHCP relay multi-instances, routing multi-instances, and independent route forwarding tables are supported. The MA5600T/MA5603T categorizes VRFs by VLANs to provide L3VPN solutions. All the packets or related protocols on the Layer 3 interface of a VRF are processed only in this VRF, which is unrelated to other VRFs. In this way, the services or users can be isolated, and the IP addresses can be saved. VRF has two application scenarios: l When the triple play service is provisioned to xDSL access users or GPON access users, different services are isolated from each other by VRF, and all services of the device are carried and go upstream by the same physical link. One VLAN Layer 3 interface can be bound to only one VR, and the upstream port belongs to multiple Layer 3 interfaces. Different VLAN Layer 3 interfaces are bound to different VRs, and each VR forwards data according to the route learned by this VR. When the triple play service is provisioned to xDSL access users or GPON access users, different services are isolated from each other by VRF, and all services of the device are carried and go upstream by two or more physical links. The links in this case are in the Layer 3 mode, and different services are isolated from each other by VRF.
The difference of the two scenarios is that dual or multiple links are adopted for upstream transmission in scenario 2, where the effect of different VRs going different "ways" is more vivid.
11 Layer 3 Features
The MA5600T/MA5603T supports the following VRF specifications: l l l l l l 63 private network VRFs and one public network VRF for the SCUN control board. 15 private network VRFs and one public network VRF for the SCUF control board. IPv4 VRF for the SCUF and SCUN control board (other control boards do not support VRF). A maximum of 32 VLAN Layer 3 interfaces in a VRF (note that one VLAN Layer 3 interface can be bound to only one VRF). Ping and trace route functions within a VRF. Binding of a static route to a BFD session for the VRF private network.
11.7.11.3 Principle VRF Compatibility

The VRF architecture is compatible with the virtual private routed network (VPRN) architecture as defined in RFC2764.
VRF Architecture
VRF is an architecture of IP networks, as shown in Figure 11-65. When users are isolated by service types or ISPs, or the users of different VPNs are prohibited from communicating with each other, multiple L3VPNs must be established in an IP network. Figure 11-65 VRF architecture
Home Gateway
VRF1 OSPF/RIP/ISIS/BGP/ Static route/ARP/DHCP VPN1
VPN1 DHCP server server
Router
VPN1 user
VRF1 VRF2 MA5600T/ IP Core VRF2 MA5603T Home OSPF/RIP/ISIS/BGP/ Gateway Static route/ARP/DHCP VPN2 DHCP server server Router VPN2
VPN2 user
The MA5600T/MA5603T VRF supports the following functions: l

Issue 01 (2011-10-30)
Creating a VRF instance

11 Layer 3 Features
You can create a VRF instance and set the name of the VRF as the reference flag through the CLI. l Adding the VLAN Layer 3 interface and the loopback interface into a VRF instance The MA5600T/MA5603T differentiates VRFs by the VLAN Layer 3 interfaces. A VRF contains one or more VLAN Layer 3 interfaces. When receiving or transmitting packets, any VLAN Layer 3 interface that belongs to the VRF must use the Layer 3 route forwarding table of the VRF. Moreover, the packets in the VRF must be forwarded between these VLAN Layer 3 interfaces and cannot be forwarded to any other VLAN Layer 3 interfaces that do not belong to the VRF. After a loopback interface is bound with the VRF instance, the loopback interface can process all the routing protocols in the VRF. The IP addresses configured in the VLAN Layer 3 interfaces of different VRFs can be identical, but the IP addresses in the same VRF cannot be identical. l Isolating ARP in a VRF The ARP in different VRFs is isolated, but the user IP addresses in different VRFs can be identical. l l Supporting independent ISIS, OSPF, RIP, or BGP routing protocol process for different VRFs Supporting the Layer 3 DHCP relay or DHCP proxy in a VRF The MA5600T/MA5603T supports the DHCP configuration based on the VLAN to implement the DHCP relay or DHCP proxy function in the VRF. l Supporting the ping and trace route functions in a VRF Ping and trace route are the basic network maintenance means. The ping function is used to check the connectivity and reachability of a remote host by sending the ping packets to the host. The trace route function is used to check the network connectivity and locate the network faults by testing the route that the data packets pass through from the host to the destination.
11.7.12 Routing Policies

11.7.12.1 Introduction to Routing Policies Definition
Routing policies are used to filter routes and control the receiving and advertising of routes. By changing route attributes (including reachability), a Router can change the path that network traffic passes through.
Purpose
When advertising, receiving, and importing routes, a Router implements certain policies according to actual networking requirements in order to filter the routes and change the attributes of the routes. Purposes of routing policies are as follows: l Controlling route advertising Only the routes that match the rules specified in a policy are advertised.
11 Layer 3 Features
Controlling route receiving Only the required and valid routes are received. This reduces the size of the routing table and improves network security.
Filtering and controlling imported routes To enrich the routing information, a routing protocol may import routing information discovered by other routing protocols. Only the routing information that satisfies the conditions is imported. Some attributes of the imported routing information are configured to meet the requirements of the protocol.
Setting the attributes for specific routes You can set attributes for the routes that match the rules.
11.7.12.2 References
None.
11.7.12.3 Basic Principle of Routing Policies

You can implement routing policies in the following steps: 1. Define rules. Define features of routing information to which routing policies are applied. That is, you need to define a set of matching rules regarding different attributes of routing information such as the destination address and AS number. Implement the rules. Apply matching rules to the routing policies for advertising, receiving, and importing routes.
2.
Currently, the following filters are provided for routing protocols: l l l l l l Access Control List (ACL) IP prefix list AS path filter Community filter Extcommunity filter Route Distinguisher (RD) filter
ACL
There are ACLs for IP packets. When defining an ACL, you can specify the IP address and subnet range to match the destination network segment address or the next hop address of a route.
IP Prefix List
An IP prefix list is identified by its name. Each IP prefix list contains multiple entries. Each entry can independently specify a matching range in the form of a network prefix. The matching range is identified by an index number that designates the matching sequence. During the matching, the device checks entries identified by the index number in an ascending order. If a route matches an entry, the route does not match the next entry.
11 Layer 3 Features
AS Path Filter
Each BGP route contains an AS path domain. AS path filters specify matching rules regarding AS path domains. AS path filters are exclusively used in BGP. For more information about the AS path attribute, refer to RFC 1965.
Community Filter
Community filters are exclusively used in BGP. Each BGP route contains a community domain to identify a community. Community filters specify matching rules regarding community domains. For more information about the community attribute, refer to RFC 1997.
Extcommunity Filter
Extended community filters (Extcommunity filters) are exclusively used in BGP. Currently, Huawei devices support filtration of routes only through the route-target (RT) extcommunity attribute of VPNs.
RD Filter
RD filters are exclusively used in BGP. RD filters specify matching rules regarding the RD attribute of VPNs.
Routing Policies
Matching rules are the core of routing policies. A route policy can use the preceding filters to define its matching rules. A route policy can consist of multiple nodes and the relationship between these nodes is OR. The system checks the nodes according to the index number. When a route matches a node in the route policy, the route does not match the next node. Each node comprises a set of if-match and apply clauses. The if-match clauses define the matching rules that are used to match certain route attributes. The relationship between the ifmatch clauses of a node is AND. A route passes the filtration of a route policy only when the route matches all the matching rules defined by the if-match clauses of the node. The apply clauses specify actions. When a route matches a node, the apply clauses set certain attributes for the route. Matching modes of a node are as follows: l Permit: If a route matches all the if-match clauses of a node, the route matches the route policy and all the actions defined by apply clauses are performed. If a route does not match any if-match clause of a node, the route continues to match the next node. Deny: If a route matches all the if-match clauses of a node, the route is denied and does not match the next node.
11.7.12.4 Application Environment

As routing policies can be flexibly used, no specific networking is required. In general, routing policies have the following two applications:
11 Layer 3 Features
filter-policy { import | export } import defines acceptable routes. That is, it determines what routes are accepted from the peer device. export defines routes to be advertised. That is, it determines what routes are sent to the peer device.
import-route (also known as Redistribute) import-route defines routing information exchange between protocols. By default, a routing protocol advertises only routing information discovered by itself. import-route allows a routing protocol to exchange routing information with other protocols and advertise routes discovered by other protocols.
11.7.12.5 BGP to IGP

BGP to IGP is an enhancement of the routing policy feature. When an IGP applies a routing policy to install BGP routes, the attributes of the routes can be set according the private attributes, such as community, extended community, and AS_path in BGP routes. Originally, when an IGP installs BGP routes, the private attributes such as community in BGP routes do not match the routing policy and the BGP routes are denied. As a result, apply clauses for configuring route attributes do not take effect. In a certain scenario shown in Figure 11-66, the IGP needs to set the cost according to the private attributes such as community in BGP routes. BGP to IGP is thus introduced. l l When an IGP installs BGP routes through a routing policy, the IGP can set the cost according to the private attributes such as community carried in BGP routes. If BGP routes carry private attributes such as community, the system obtains the private attributes and filters the BGP routes according to the routing policy. If the private attributes match the routing policies, the BGP routes are permitted by the system and apply clauses take effect. If BGP routes do not carry private attributes such as community, the BGP routes do not match the routing policy and are denied by the system. In this case, apply clauses do not take effect.
BGP to IGP Applications

As shown in Figure 11-66, the IS-IS relationship is set up between Router A and Router B that are in the same AS. EBGP connections are established between Router B and Router C. Router A is a non-BGP device in the AS. When IS-IS installs BGP routes and applies a routing policy, IS-IS can change the cost according to the private attributes such as community in the matched BGP routes. Figure 11-66 Networking diagram of BGP to IGP
AS65008
AS65009
RouterA
RouterB
RouterC
Issue 01 (2011-10-30)
377
11 Layer 3 Features
11.7.12.6 Terms and Abbreviations Abbreviations

Abbreviatio ns FIB IBGP EBGP ACL USR RM Full Spelling Forwarding Information Base Internal Border Gateway Protocol External Border Gateway Protocol Access Control List Unicast Static Route Route Management
11.7.13 ECMP
Equal and Weighted Cost Multi-Path (ECMP) is a technique in which if two or more equal cost shortest paths exist between two nodes, the traffic between the nodes is distributed among the multiple equal-cost paths.

Equal and Weighted Cost Multi-Path (ECMP) is a technique in which if two or more equal cost shortest paths exist between two nodes, the traffic between the nodes is distributed among the multiple equal-cost paths. That is, in packet transmissions, if different routes with the same destination network exist in the system, the packets can be transmitted to the destination network through multiple next hops.
Purpose
In ECMP, the traffic to the same destination network can be distributed among multiple equalcost paths to reduce the network load, and the links in the network can back up each other. That is, when a link in the network fails, the packets on this link can be forwarded to the destination network through other links that are in the normal state.
The MA5600T/MA5603T supports the following ECMP specifications: l l In different routing instances, the MA5600T/MA5603T supports up to two ECMP routes. The ECMP routes support up to 128 different next hops, and the number of the destination IP addresses cannot exceed 64.
Issue 01 (2011-10-30)
11 Layer 3 Features
11.7.13.3 Principle
In ECMP, according to different states of the network, the traffic to the same destination network can be distributed among multiple equal-cost paths to reduce the network load or to implement the link backup function. As shown in Figure 11-67, assume that a packet is transmitted to the destination network (192.16.5.0) through Routers A-D, and two routes to the destination network exist in Router A. When receiving the packet from a user, Router A can select Router B or Router C as the next hop to forward the packet to the destination network. Figure 11-67 ECMP diagram
Router B 192.16.1.0/24 Router A 192.16.5.0/24
Router D 192.16.2.0/24 PC Router C
Issue 01 (2011-10-30)
379
12 IPv6
12
About This Chapter
12.1 Introduction to IPv6 12.2 Reference Standards and Protocols 12.3 Availability 12.4 Principles 12.5 IPv6 Features Supported by the MA5600T/MA5603T 12.6 Application 12.7 Terms and Abbreviations
IPv6
This chapter provides an introduction to Internet Protocol Version 6 (IPv6), the principles of IPv6, and IPv6 applications.
Issue 01 (2011-10-30)
380
12 IPv6
12.1 Introduction to IPv6

Definition
Internet Protocol Version 6 (IPv6), also called IP Next Generation (IPng), is the secondgeneration standard protocol of network layer protocols. As a set of specifications defined by the Internet Engineering Task Force (IETF), IPv6 is the upgraded version of Internet Protocol Version 4 (IPv4). The most obvious difference between IPv6 and IPv4 is that IP addresses are lengthened from 32 bits to 128 bits. Featuring the simplified header format, sufficient address space, hierarchical address structure, flexible extended header, and enhanced neighbor discovery (ND) mechanism, IPv6 is competitive in the future market. MA5600T/MA5603T supports IPv6 on the following interfaces: l l l l l l l l Ethernet interfaces and sub-interfaces Gigabit-Ethernet interfaces and sub-interfaces Serial interfaces (Only the Serial interfaces configured with PPP or HDLC as the link protocol support IPv6.) POS interfaces (Only the POS interfaces configured with PPP or HDLC as the link protocol support IPv6.) Tunnel interfaces Loopback interfaces Eth-Trunk interfaces, Eth-Trunk sub-interfaces, and IP-Trunk interfaces VLANIF interfaces
Purpose
The IPv4-based Internet achieves a great success. Consequently, the IP technology is widely applied. With the rapid development of the Internet, however, deficiencies in IPv4 become increasingly obvious in the following aspects: l The IPv4 address space is insufficient. An IPv4 address is identified by using 32 bits. In theory, a maximum of 4.3 billion addresses can be provided. In actual applications, less than 4.3 billion addresses are available because of address allocation. In addition, IPv4 address resources are allocated unevenly. Address resources of the USA occupy almost half of the global address space; the address resources of Europe are relatively fewer than those of the USA; the address resources of the AsianPacific region are much fewer. The development of mobile IP and broadband technology requires more IP addresses. Consequently, limited IPv4 address resources directly restrict the further development of the IP technology. There are several solutions to IPv4 address shortage. Classless Interdomain Routing (CIDR) and Network Address Translator (NAT) are two representative solutions to IPv4 address shortage. CIDR and NAT, however, have their disadvantages and unsolved problems. This promotes the development of IPv6. l The backbone device maintains too many routing entries. Many discontinuous IPv4 addresses are allocated because of the problems in the initial IPv4 address allocation planning. As a result, routes cannot be aggregated effectively. The increasingly large routing table consumes a lot of memory, degrading forwarding
12 IPv6
efficiency. Subsequently, device manufacturers have to upgrade products to improve route addressing and forwarding performance. l Address autoconfiguration and readdressing cannot be performed easily. An IPv4 address occupies only 32 bits and IP addresses are allocated unevenly. Consequently, IP addresses need to be reallocated during network expansion or network replanning. Address autoconfiguration and readdressing are required to simplify maintenance. l Security cannot be well guaranteed. As the Internet develops, security problems become more serious. The IPv4 design does not fully consider security, so the original framework cannot ensure end-to-end security. IPv6 provides end-to-end security by using IP security (IPSec) as the standard extended header. IPv6 radically solves the problem of IP address shortage. Moreover, IPv6 has the following advantages: It is easy to deploy, compatible with various applications, easy for IPv4 networks to transit to IPv6 networks, and coexists and interworks with IPv4 networks. With so many obvious advantages over IPv4, IPv6 is rapidly developed.

The following table lists the reference standards and protocols of the IPv6 feature. Standard/ Protocol RFC793 RFC768 RFC1981 RFC2460 Description Transmission Control Protocol User Datagram Protocol Path MTU Discovery for IP version 6 Version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. Neighbor Discovery for IP Version 6 (IPv6) Internet Control Message Protocol for the Internet Protocol Version 6 Specification Management Information Base for IP Version 6: Textual Conventions and General Group RFC2466 Management Information Base for IP Version 6: ICMPv6 Group Remarks
RFC2461 RFC2463
RFC2465
Issue 01 (2011-10-30)
382
12 IPv6
Standard/ Protocol RFC2473 RFC2711 RFC2893 RFC3056 RFC3972 RFC4191 RFC4214 RFC4291 RFC4443
Description Generic Packet Tunneling in IPv6 Specification IPv6 Router Alert Option Transition Mechanisms for IPv6 Hosts and Routers Connection of IPv6 Domains via IPv4 Clouds Cryptographically Generated Addresses (CGA) Default Router Preferences and More-Specific Routes Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Internet Protocol Version 6 (IPv6) Addressing Architecture Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Neighbor Discovery for IP version 6 (IPv6)
Remarks
RFC4861
12.3 Availability
License Support
The IPv6 feature is a basic feature of the MA5600T/MA5603T. Therefore, the corresponding service is provided without a license.
Version Support
Table 12-1 lists the MA5600T/MA5603T versions that support the IPv6 feature. Table 12-1 Version support Product MA5600T/MA5603T Version V800R009 and later versions
Issue 01 (2011-10-30)
383
12 IPv6
Hardware Support
Table 12-2 lists the MA5600T/MA5603T boards that support the IPv6 feature. Boards in the following table support all IPv6 functions listed in 12.5 IPv6 Features Supported by the MA5600T/MA5603T, unless otherwise specified. Table 12-2 Board Support for IPv6 Board Type Control Board Details SCUN SCUL: not support the MP-BGP feature. SCUB: not support the MP-BGP feature. SCUF: not support the VRF6 feature. VDSL Board ADSL Board SHDSL Board H805VDMF, H805VDRD, H80BVDPE, H80BVDPM. H805ADPD, H802ADKM, H802ADPD, H80BCAME, H80BADPE, H805ADLF. H80ASHLM, H803SHDA H802SHLB: only support to capture the IPv6 protocol message. P2P Board H802OPGD ETHB: only support to capture the IPv6 protocol message. GPON Board SPU Board GPBD SPUA: only support to capture the IPv6 protocol message.
12.4 Principles
Basic functions of IPv6 include IPv6 neighbor discovery and IPv6 path MTU (PMTU) discovery. Neighbor discovery and PMTU discovery are implemented through Internet Control Message Protocol for IPv6 (ICMPv6) messages.
12.4.1 IPv6 Addresses

Format of an IPv6 Address
A 128-bit IPv6 address has two formats: l X:X:X:X:X:X:X:X In this format, a 128-bit IPv6 address is divided into eight groups. The 16 bits of each group are represented by four hexadecimal characters, that is, 0 to 9, and A to F. Groups are separated by colons. Every "X" represents a group of hexadecimal numbers. The following is an example: 2031:0000:130F:0000:0000:09C0:876A:130B For convenience, the preceding zeros in each group can be omitted. Therefore, the preceding example can be written as 2031:0:130F:0:0:9C0:876A:130B.
12 IPv6
Furthermore, two or more consecutive zeros in the address can be replaced by "::". Then, the preceding example can be further compressed as 2031:0:130F::9C0:876A:130B. An IPv6 address contains only one "::". Otherwise, a computer cannot determine the number of zeros when restoring the compressed address to the original 128-bit address. l X:X:X:X:X:X:d.d.d.d The following types of addresses are in this format: IPv4-compatible IPv6 address: The format of an IPv4-compatible IPv6 address is 0:0:0:0:0:0:IPv4-address. The high-order 96 bits are all 0s, and the low-order 32 bits specify an IPv4 address. This IPv4 address must be reachable in the IPv4 network, and cannot be a multicast address, a broadcast address, a loopback address, or an unspecified address (0.0.0.0). IPv4-mapped IPv6 address: The format of an IPv4-mapped IPv6 address is 0:0:0:0:0:FFFF:IPv4-address. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. An IPv4-compatible IPv6 address is used for the configuration of IPv6 over IPv4 tunnels. "X:X:X:X:X:X" represent the high-order six groups of numbers, and each "X" stands for 16 bits that are represented by hexadecimal numbers. "d.d.d.d" represent the low-order four groups of numbers, and each "d" stands for 8 bits that are represented by decimal numbers. "d.d.d.d" is a standard IPv4 address.
Structure of an IPv6 Address

An IPv6 address can be divided into two parts: l l Network prefix: equals the network ID of an IPv4 address. It is of n bits. Interface identifier: equals the host ID of an IPv4 address. It is of 128-n bits.
Figure 12-1 illustrates the structure of the address 2001:A304:6101:1:0:E0:F726:4E58 /64. Figure 12-1 Structure of the address 2001:A304:6101:1:0:E0:F726:4E58 /64
Nework prefix 64 bits
Interface ID 64 bits
2001:A304:6101:0001
0000:00E0:F726:4E58
IPv6 Address Classification

IPv6 has the following types of addresses: l Unicast address: uniquely identifies an interface and is similar to an IPv4 unicast address. The packets sent to a unicast address are transmitted to the unique interface identified by this address. Unicast addresses can be classified into the following types, as shown in Table 12-3.
12 IPv6
Table 12-3 Type of IPv6 unicast address Address Type Link-local unicast address Loopback address Unspecified address Global unicast address Binary Prefix 1111111010 00...1 (128 bits) 00...0 (128 bits) Others IPv6 Prefix Identifier FE80::/10 ::1/128 ::/128 -
The meanings of each type of addresses are described as follows: Link-local IPv6 unicast address: is used in the neighbor discovery protocol, and in the communication between nodes on the local link during the stateless address autoconfiguration. The packets with the link-local IPv6 unicast address as the source or destination address are forwarded only on the local link. The link-local IPv6 unicast address can be automatically configured on any interface by using the link-local prefix FE80::/10(1111 1110 10), and the interface identifier in the IEEE EUI-64 format (an EUI-64 can be derived from an EUI-48). Loopback address: is 0:0:0:0:0:0:0:1 or ::1 and not assigned to any interface. Similar to the IPv4 loopback address 127.0.0.1, the IPv6 loopback address indicates that a node sends IPv6 packets with the destination as itself. Unspecified address (::): cannot be assigned to any node or function as destination addresses. The unspecified address can be used in the Source Address field of the IPv6 packet sent by an initializing host before it has learned its own address. During Duplicate Address Detection (DAD), the Source Address field of a Neighbor Solicitation (NS) packet is an unspecified address. Global unicast address: is equivalent to an IPv4 public network address. Global unicast addresses are used on the links that can be aggregated, and are provided to the Internet Service Provider (ISP). The structure of this type of addresses enables route-prefix aggregation to solve the problem of the limited number of global routing entries. A global unicast address consists of a 48-bit route prefix managed by operators, a 16-bit subnet ID managed by local nodes, and a 64-bit interface ID. Unless otherwise specified, global unicast addresses include site-local unicast addresses. l Anycast address: identifies a group of interfaces, which generally belong to different nodes. The packets with an anycast destination address are transmitted to the interface that is nearest to the source node in the interface group identified by the anycast address. The nearest interface refers to the interface of the smallest metric measured by the routing protocol. Applicable environment: When a mobile host needs to communicate with the mobile agent on the home subnet, it uses the anycast address of the device of the subnet. Specifications of addresses: Anycast addresses do not have independent address space. They can use the format of any unicast address. Therefore, a syntax is required to differentiate an anycast address from a unicast address. l Multicast address: identifies a group of interfaces that belong to different nodes and is similar to an IPv4 multicast address. The packets with a multicast destination address are transmitted to all the interfaces identified by this multicast address.
Issue 01 (2011-10-30)
386
12 IPv6
IPv6 addresses do not include broadcast addresses. In IPv6, multicast addresses can provide the functions of broadcast addresses.
Interface ID in the IEEE EUI-64 Format

The 64-bit interface ID in an IPv6 address identifies a unique interface on a link. This address is derived from the link-layer address (such as a MAC address) of the interface. The 64-bit IPv6 interface ID is transformed from a 48-bit MAC address by inserting a hexadecimal number FFFE (1111 1111 1111 1110) into the MAC address and then setting the U/L bit (the leftmost seventh bit) to 1. Figure 12-2 shows transformation from a MAC address to an EUI-64 address. Figure 12-2 Transformation from a MAC address to an EUI-64 address MAC: 0012:3400:ABCD
Binary: 00000000 00010010 00110100 00000000 10101011 11001101 Insert FFFE: 00000000 00010010 00110100 1111111111111110 00000000 1010101111001101 Set U/L bit: 00000010 00010010 00110100 11111111 11111110 00000000 10101011 11001101 EUI-64: 0212:34FF:FE00:ABCD
12.4.2 IPv6 Characteristics

l 128-bit address structure, providing sufficient address space The major benefit that IPv6 brings is the almost infinite IP address space. IPv6 increases the IP address size from 32 bits to 128 bits, four times of IPv4. A 128-bit address structure is able to provide about 4,300,000,0004 addresses, which meets any predictable address assignment requirements. l Hierarchical address structure The hierarchical address structure helps quickly look up routes, reduce the size of IPv6 routing table with the assistance of route aggregation, and improve the forwarding efficiency of routers. l Address autoconfiguration IPv6 enables hosts to discover networks and obtain IPv6 addresses using address autoconfiguration, which greatly improves the network manageability. Using address autoconfiguration, user devices (such as mobile phones and wireless devices) support plugand-play, without manual configuration or using a private server (such as the DHCP server). IPv6 supports stateful address autoconfiguration and stateless address autoconfiguration. In stateful address autoconfiguration, the host obtains the address and configuration information from the server. In stateless address autoconfiguration, the host automatically configures the address information that contains the prefix and interface ID of the host reported by the local
12 IPv6
router. If there is no router on the link, the host can automatically configure only the link-local address for interoperation with the local node. l Source/Destination address selection To specify or plan source/destination addresses of the packets sent by the system, the network administrator can define a set of address selection rules. These rules form the address selection policy table. The policy table is a longest-matching-prefix lookup table, similar to a routing table. The address selection result is determined by the source address and destination address together. A source address is selected according to the following rules (note that the rule with a smaller number has a higher priority): 1. 2. 3. 4. 5. 6. 7. Prefer same source and destination address. Prefer appropriate scope. Avoid deprecated addresses. Prefer home addresses. Prefer outgoing interface. Prefer matching label (the label value of the source address is the same as that of the destination address). Use longest matching prefix.
NOTE
The candidate address can be the unicast address that is configured on the specified outgoing interface. If a source address that has the same label value and is in the same address range with the destination address is not found on the outgoing interface, such a source address can be selected on another interface.
A destination address is selected according to the following rules (note that the rule with a smaller number has a higher priority): 1. 2. 3. 4. 5. 6. 7. 8. 9. l QoS New fields in the IPv6 header define how to identify and process flows. Flows are identified by the Flow Label field in the header. The Flow Label field allows routers to identify the packets of a certain flow and to provide special processing for these packets. IPv6 can provide QoS guarantee even for the IPsec-encrypted packet payload because the IPv6 header can identify flows. l End-to-end security IPv4 supports IPsec using options. In actual deployment, most of the IPv4 nodes do not support IPsec. IPsec is a basic part in IPv6, and any IPv6 nodes deployed support IPsec.
Avoid unusable destination addresses. Prefer matching scope. Avoid deprecated addresses. Prefer home addresses. Prefer matching label (the label value of the source address is the same as that of the destination address). Prefer higher precedence. Prefer native transport (6over4 or 6to4 tunnel is not required). Prefer smaller scope. Use longest matching prefix.
10. Otherwise, leave the order unchanged.
12 IPv6
Therefore, it is much easier to provide end-to-end security in IPv6. IPv6 supports security goals defined for IP network: confidentiality (only anticipated receivers are able to read the data), integrity (data is not tampered during transmission), and authenticity (entities sending data are who they claim they are). l Flexible and simple extension headers Figure 12-3 shows comparison between the IPv6 header format and IPv4 header format. Compared with an IPv4 header, an IPv6 header deletes the IHL, Identification, Flags, Fragment Offset, Header Checksum, Options, and Padding fields and adds the Flow Label field, which helps improve the header processing efficiency. In addition, to better support different options, IPv6 introduces multiple extension headers. With these extension headers, it is unnecessary to modify the current packet structure for adding options, which improves the flexibility of IPv6. Figure 12-3 Comparison between the IPv6 header format and IPv4 header format
IPv4 header Version IHL Type of Service Flags Protocol Total Length Flagment Offset Identification Time to Live
Header Checksum
Source Address Destination Address Options IPv6 header Version Traffic Class Flow Label Next Header Hop Limit New fields in IPv6 Source Address Payload Length Padding Deleted fields in IPv6 Fields in both IPv6 and IPv4 Modified fields in IPv6 (name and position)
Destination Address
12.4.3 IPv6 Packet Format

Format of an IPv6 Header
Figure 12-4 shows the format of an IPv6 header.
Issue 01 (2011-10-30)
389
12 IPv6
Figure 12-4 Format of an IPv6 header
Version
Traffic Class
Flow Label Next Header Source Address Hop Limit
Payload Length
Destination Address
l l l
Version: 4 bits. The value of this field is 6, indicating an IPv6 packet. Traffic Class: 8 bits. This field is similar to the IPv4 TOS field. Flow Label: 20 bits. This field is new in IPv6. Flow labels are used to differentiate packets at the network layer. Routers along a forwarding path differentiate and process packets according to the flow labels. Because the Flow Label field is in the IPv6 header, forwarding routers and destination nodes do not need to differentiate packets according to the packet content. Also because of this, QoS processing can be performed on packets according to flow labels even after packets are processed using IPsec.
Payload Length: 16 bits. This field indicates the length of the IPv6 payload (the rest of the packet following the IPv6 header), in octets. (Note that any extension headers present are considered part of the payload.)
Next Header: 8 bits. This field identifies the type of header immediately following the current IPv6 header (header or extension header). It uses the same values as the IPv4 Protocol field. Next Header fields in the IPv6 header and IPv6 extension headers form a chain, which helps improve the efficiency of processing extension headers.
Hop Limit: 8 bits. This field is similar to the IPv4 TTL field. This field is decreased by 1 by each node that forwards the packet. The packet is dropped if this field is decreased to 0.
l l
Source Address: 128 bits. This field indicates the source address of the packet. Destination Address: 128 bits. This field indicates the destination address of the packet.
Format of IPv6 Extension Headers

Figure 12-5 shows the format of IPv6 extension headers.
12 IPv6
Figure 12-5 Format of IPv6 extension headers
Version
Traffic Class
Payload Length
Destination Address Next Header Extension Header Len Extension Head Data Next Header Extension Header Len Extension Head Data Next Header Extension Header Len Extension Head Data
Next Header
Extension Header Len Extension Head Data(last)
IPv6 option fields are supported by a chain of extension headers. An IPv6 packet can carry zero, one, or more extension headers. IPv6 extension headers appear in the following order: l Hop-by-Hop Options header The value of this header is 0 (defined in the IPv6 header). It is used for routing alarms (RSVP and MLDv1) and jumbo frames. This header is processed by every node along the packet forwarding path. l Destination Options header The value of this header is 60. This header may occur before the following two headers: Routing header The Destination Options header is processed by the destination node and the node specified in the Routing header. Upper-layer header (after any ESP option) The Destination Options header is processed only by the destination node. Mobile IPv6 uses the Destination Options header.
12 IPv6
Routing header The value of this header is 43. This header is used for source routing options and mobile IPv6.
Fragment header The value of this header is 44. This header is used for packet fragmentation when the packet sent by the source node is larger than the path MTU (MTU in the path from the source node to destination node).
Authentication header The value of this header is 51. This header is used for IPsec, authenticating and checking the integrity of a packet. The definition of this header in IPv6 is the same as that in IPv4.
ESP header The value of this header is 50. This header is used for IPsec, authenticating, encrypting and checking the integrity of a packet. The definition of this header in IPv6 is the same as that in IPv4.
Upper-layer header This header is an upper-layer protocol (TCP/UDP/ICMP) header.
The Destination Options header occurs at most twice (once before the Routing header and once before the upper-layer header), and the other extension headers occur at most once. IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header that is restricted to appear immediately after an IPv6 header only. This ensures good interoperation between IPv6 nodes.
12.4.4 ICMPv6
As one base protocol of IPv6, Internet Control Message Protocol for IPv6 (ICMPv6) generates error messages and informational messages, which are used by IPv6 nodes to report errors and information generated during packet processing. Figure 12-6 shows the format of an ICMPv6 message. Figure 12-6 Format of an ICMPv6 message 0 Type (1) 7 Code (1) Packet Content ...... 15 23 Checksum (2) 31
The meaning of each field in an ICMPv6 message is as follows: l l l

Issue 01 (2011-10-30)
Type field: indicates the message type. The values from 0 to 127 indicate the error message type, and values from 128 to 255 indicate the informational message type. Code field: indicates the specific message type. Checksum field: indicates the checksum of an ICMPv6 message.
12 IPv6
Classification of ICMPv6 Error Messages

l Destination Unreachable message When an IPv6 node forwards IPv6 packets, if it detects that the destination address of the packets is unreachable, it sends an ICMPv6 Destination Unreachable message to the source node of the packets. Specific causes for the error message are carried in the message. Destination Unreachable messages are classified into the following types: No route to destination Address Unreachable Port Unreachable l Datagram Too Big message When an IPv6 node forwards IPv6 packets, if it detects that the size of the packets exceeds the path MTU of the outbound interface, it sends an ICMPv6 Datagram Too Big message to the source node of the packets. The path MTU of the outbound interface is carried in the message. Path MTU discovery is implemented based on Datagram Too Big messages. l Time Exceeded message During the transmission of IPv6 packets, when a device receives a packet with the hop limit being 0 or a device reduces the hop limit to 0, it sends an ICMPv6 Time Exceeded message to the source node of the packets. During the processing of a packet to be fragmented and reassembled, an ICMPv6 Time Exceeded message is also generated when the reassembly time is longer than the specified period. l Parameter Problem message When a destination node receives an IPv6 packet, it checks the validity of the packet. If it detects the following errors, it sends an ICMPv6 Parameter Problem message to the source node of the packet: A field in the IPv6 basic header or extension header is incorrect. The NextHeader in the IPv6 basic header or extension header cannot be identified. Unknown options exist in the extension header.
Classification of ICMPv6 Informational Messages

ICMPv6 informational messages are classified into Echo Request messages and Echo Reply messages. ICMPv6 messages can be used for network fault diagnosis, path MTU discovery, and neighbor discovery. During the detection of interworking between two nodes, the node that receives an Echo Request message sends an Echo Reply message to the source node. In this manner, packets are transmitted between the two nodes.
12.4.5 Neighbor Discovery

Neighbor discovery (ND) is a set of messages and processes used for determining the relationship between neighboring nodes. The ND protocol for IPv6 supports Address Resolution Protocol (ARP), ICMP Router Discovery, and ICMP Redirect of IPv4 and also provides other functions. After an IPv6 address is configured on a node, the node first verifies that the address is available and does not conflict with other addresses. If the node is a host, the router needs to notify the host of a better first-hop address to reach a particular destination. If the node is a router, this node needs to advertise its address, address prefix, and other parameters, which provides guidance for the host to configure parameters. During IPv6 packet forwarding, a node needs to verify the link-layer address and reachability of its neighboring node. IPv6 ND defines five types of ICMPv6 packet:
12 IPv6
l l l
Router Solicitation (RS): Sent by an enabled host to a router. The router then responds with a Router Advertisement (RA). RA: Advertised by a router periodically, which contains information such as the prefix and some flags. Neighbor Solicitation (NS): Sent by an IPv6 node to determine the link-layer address of a neighbor, to check whether a neighbor is reachable, or for duplicate address detection (DAD). Neighbor Advertisement (NA): A response to an NS. An IPv6 node may also send unsolicited NAs to announce a link-layer address change. Redirect: Used by a router to inform hosts of a better first hop for a specific destination when the router finds that the incoming interface and outgoing interface of the packets are the same.
l l
The ND protocol for IPv6 has the following functions.
Duplicate Address Detection(DAD)

DAD is a detection mechanism used for determining whether an IPv6 address is available. The process is as follows: 1. 2. 3. When an IPv6 address is configured on a node, the node sends an NS to its neighboring node to check whether the IP address is already used. When receiving the NS, the neighboring node checks whether it has the same IPv6 address. If yes, the neighboring node responds with an NA carrying the IPv6 address information. The node, upon receiving the NA, considers that the IPv6 address configured is already used by its neighboring node. If the node does not receive any response packet from its neighboring node, the IPv6 address configured is available.
Neighbor Discovery
ND for IPv6, similar to ARP in IPv4, is used to parse the addresses of neighbors and detect whether neighbors are reachable using NSs and NAs. To obtain the link-layer address of another node in the same local link, a node (source node) sends an NS with its ICMPv6 type as 135. This packet is similar to an ARP request packet in IPv6; but unlike the ARP request packet using a broadcast address, the NS uses a multicast address. A node with the last 24 bits of its address the same as the multicast address will receive this NS, which reduces the possibility of broadcast storm. The node receiving the NS (destination node) fills in its link-layer address in the response packet. An NS can also be used to check whether a neighboring node is reachable when the link-layer address of the neighboring node is known. An NA is the response packet of an NS. The destination node, upon receiving an NS, responds with an NA with its ICMPv6 type as 136 over the local link. The source node then is able to communicate with the destination node after receiving the NA. A node may also send unsolicited NAs to announce a link-layer address change on the local link.
Router Discovery
Router Discovery is used to locate neighboring routers as well as learn prefixes and configuration parameters related to stateless address autoconfiguration. Router Discovery in IPv6 is implemented using the following two mechanisms:
12 IPv6
Router Solicitation (RS) message When unicast addresses are not configured on a host (for example, the system just starts up), the host sends an RS. An RS facilitates the host autoconfiguration, without having to wait for the RA sent by IPv6 routers. An RS packet is an ICMPv6 packet of type 133.
Router Advertisement (RA) message Each RA-enabled IPv6 router periodically sends RAs. After receiving an RS from an IPv6 node on the local link, an IPv6 router also responds with an RA. An IPv6 router sends an RA to the multicast addresses (FF02::1) of all nodes or to the IPv6 unicast address of the node sending an RS. An RA is an ICMPv6 of type 134, including the following content: Whether to use address autoconfiguration Supported autoconfiguration type (stateless or stateful) One or more local link prefixes (nodes on the local link can use these prefixes to perform address autoconfiguration) Lifetime of local link prefixes advertised Whether the router sending an RA can serve as a default router. If yes, the information also contains the lifetime of the default router in units of seconds. Other host-related information, such as the hop limit and the MTU used for the host to send packets An IPv6 node on the local link receives an RA and updates information such as the default router, prefix list, and other information from this RA.
Address Autoconfiguration
RAs and per-prefix flags enable routers to inform hosts how to perform address autoconfiguration. For example, routers can specify whether hosts use stateful (DHCPv6) or stateless address configuration. In stateless address autoconfiguration, a host uses the prefix information and local interface ID obtained from the RA received to automatically generate an IPv6 address. Also, the host can set the default router according to the default router information in the RA.
Redirect
Redirect messages are sent by routers to inform a host of a better first-hop IPv6 address for a specific destination. Like IPv4, IPv6 Redirect packets are sent only for redirecting packets to a better router. Nodes receiving these Redirect packets will send packets to this better router. Routers send Redirect packets only for unicast flows, and Redirect packets are only sent to and processed by those nodes (hosts) triggering redirect.
Default Router Priority and Routing Information

An RA defines two fields: default router priority and routing information, which helps hosts select a better forwarding router for packets. When the link where a host resides has multiple routers, the host needs to select the forwarding router according to the packet's destination address. In such cases, routers advertise default router priority and specific routing information to hosts, improving hosts' capability of selecting better forwarding routers according to different destination addresses.
12 IPv6
A host, upon receiving an RA that contains the routing information, will update its routing list. Before sending packets to other devices, the host selects a better route according to its routing list. A host updates its default router list after receiving an RA that contains default router priority information. Before sending packets to other devices, the host queries its default router list and selects the highest-priority router for sending packets if no route is available. If the highestpriority router is faulty, the host will choose the second-highest-priority router and so on.
12.4.6 Path MTU

Problems Related to the MTU
During transmission, IPv6 packets cannot be fragmented on the transit node, so packet length is often greater than the path MTU (PMTU). The source node then needs to retransmit the IPv6 packets continuously. This reduces transmission efficiency. If the source node uses the minimum IPv6 MTU of 1280 bytes as the maximum fragment length, in most cases, the PMTU is greater than the minimum IPv6 MTU of the link, and the fragments sent by a node are always smaller than the PMTU. As a result, network resources are wasted. The PMTU discovery protocol is introduced to solve this problem.
Principle of the Path MTU

PMTU is the process of discovering the minimum IPv6 MTU on the path from the source to the destination. PMTU discovery describes a method of dynamically discovering the PMTU for a path. When an IPv6 node sends a great deal of data to another node, data is transmitted through a series of IPv6 fragments. When these fragments are of the maximum length allowed in successful transmission between the source node and destination node, the fragment length is considered optimal and called PMTU. A source node assumes that a PMTU of a path is the known IPv6 MTU of the first hop on the path. If the packet sent from this path is too large to be forwarded along the path, the transit node discards this packet and returns an ICMPv6 Datagram Too Big message to the source node. The source node then sets the PMTU of the path according to the IPv6 MTU in the message. When the PMTU learned by the node is smaller than or equal to the actual PMTU, the PMTU discovery process is complete. Before the PMTU discovery process is complete, ICMPv6 Datagram Too Big messages may be repeatedly sent and received because smaller IPv6 MTUs may be found on farther paths.
12.4.7 Dual Protocol Stacks

An IPv6 node that retains the complete IPv4 protocol stack to be compatible with IPv4 is a dualstack node. Figure 12-7 shows the structure of a single protocol stack and dual protocol stacks.
Issue 01 (2011-10-30)
396
12 IPv6
Figure 12-7 Structure of a single protocol stack and dual protocol stacks in Ethernet
IPv4 Application TCP UDP
IPv4/IPv6 Application TCP UDP
IPv4 Protocol ID: 0x0800 Ethernet IPv4 Stack
IPv4
IPv6 Protocol ID: Protocol ID: 0x86DD 0x0800 Ethernet Dual Stack
Dual protocol stacks have the following advantages: l Multiple link protocols support dual protocol stacks. Multiple link protocols, such as Ethernet, support dual protocol stacks. In Figure 12-7, the link protocol is Ethernet. In an Ethernet frame, if the Protocol ID field is 0x0800, it indicates that the network layer receives IPv4 packets; if it is 0x86DD, it indicates that the network layer receives IPv6 packets. l Multiple applications support dual protocol stacks. Multiple applications, such as the DNS, FTP, and Telnet, support dual protocol stacks. The upper layer application such as the DNS can use TCP or UDP as the transmission layer protocol, and prefers the IPv6 protocol stack rather than the IPv4 protocol stack as the network layer protocol.
12.4.8 TCP6
Transmission Control Protocol Version 6 (TCP6) provides a mechanism to establish virtual circuits between processes of two endpoints. A TCP6 virtual circuit is similar to the full-duplex circuit that transmits data between systems. Providing reliable data transmission between processes, TCP6 is called a reliable protocol. TCP6 also provides a mechanism to optimize the transmission performance according to the network status. When all the data can be received and acknowledged, the transmission rate increases gradually. However, delay causes the sending host to decrease the sending rate before it receives Acknowledgement packets. TCP6 is generally used in interactive applications, such as the Web. However, certain errors in data receiving affect the normal operation of devices. TCP6 establishes virtual circuits by using the three-way handshake mechanism, and all the virtual circuits are deleted through the fourway handshake. TCP6 connections provide multiple checksums and reliability functions, but increase the cost. As a result, TCP6 has lower efficiency than User Datagram Protocol Version 6 (UDP6). Figure 12-8 shows the establishment and removal of a TCP6 connection.
Issue 01 (2011-10-30)
397
12 IPv6
Figure 12-8 Establishment and removal of a TCP6 connection

Client Call the socket and receive its return value Call the connect function Wait SYN SYN|ACK ACK Data Server Call the socket and receive its return value Call the bind/listen function and receive their return values Call the accept function Wait
Receive the return value of connect Call the recv function Wait Receive the return Data value of recv transmission Call the send function Call the close function and receive its return value
Set up a connection
Receive the return value of accept Call the send function and receive its return value Call the recv function Data|ACK Wait Receive the return value of recv
ACK FIN ACK FIN ACK
Call the recv function Wait Receive the return value 0 of recv Call the close function and receive its return value
Close the connection
12.4.9 UDP6
User Datagram Protocol Version 6 (UDP6) is a computer communication protocol used to exchange packets on a network. UDP6 has the following characteristics: l l l UDP uses only source and destination information and is mainly used in the simple request/ response structure. UDP is unreliable, so it cannot be determined whether UDP6 datagrams reach their destinations. UDP is connectionless. That is, no virtual circuits are required during data transmission between hosts.
The connectionless feature of UDP6 enables UDP6 to send data to broadcast addresses. This is different from TCP6, which requires specific source and destination addresses.
12.4.10 RawIP6
RawIP6 fills only a limited number of fields in the IPv6 header, and it allows application programs to provide their own IPv6 headers. RawIP6 is similar to UDP6 in the following aspects: l l RawIP6 is unreliable, so it cannot be determined whether RawIP6 datagrams reach their destinations. RawIP6 is connectionless. That is, no virtual circuits are required during data transmission between hosts.
Unlike UDP6, RawIP6 allows application programs to directly operate the IP layer through the socket. This facilitates the direct interactions with the lower layer.
12 IPv6
12.5 IPv6 Features Supported by the MA5600T/MA5603T

The MA5600T/MA5603T provides the following features to ensure IPv6 application. This section covers unique IPv6 features as well as its differences from IPv4, but does not cover its features that are the same as IPv4. For details about the common features of IPv6 and IPv4, see the specific feature description. Table 12-4 IPv6 features supported by the MA5600T/MA5603T Feature IPv6 address management and assignment Sub-feature Static configuration of IPv6 global unicast addresses and IPv6 link-local addresses Automatic configuration of IPv6 link-local addresses DHCPv6, DHCPv6 L2/L3 Relay Management information base (MIB) for IPv6 address management IPv6 stack and IPv6 host function IPv6/IPv4 dual-stack to ensure compatibility of IPv6 and IPv4 Basic IPv6 protocols, including ICMPv6, TCP6, UDP6, and RawIP6 IPv6 packet processing on the Layer 3 interface IPv6 Neighbor Discovery (ND) protocol and static configuration of IPv6 neighbors IPv6 PMTU IPv6 ping and tracert IPv6 statistics query and clearance IPv6 route IPv6 static routes MP-BGP IPv6 QoS and security IPv6 ACL Anti-MAC spoofing and 1:1 VMAC Anti-IPv6 spoofing Anti-denial of service (DoS) attack DAD Proxy Proxy advertisement for neighbor solicitation (NS) on the network side
Issue 01 (2011-10-30)
399
12 IPv6
Feature IPv6 Layer 2 Transparent Transmission
Sub-feature Differentiation of service virtual ports based on the IPv6 over Ethernet (IPv6oE) type (0x86DD) and defining of VLANs for service virtual ports Transparent transmission of IPv6 over PPPoE packets VLAN-based transparent transmission of IPv6 packets
12.5.1 Routing
This topic describes the differences between IPv4 and IPv6 routing in specifications and principle.
Specifications
The differences between IPv4 and IPv6 in routing specifications lie in static route, BGP, and VRF. Table 12-5 The differences between IPv4 and IPv6 in routing specifications Contro l boards SCUB IPV4 Routes (max) 5120 Static Route 4096 BGP 2300 VRF Not support ed Not support ed Support ed Support ed IPV6 Routes (max) 5120 Static Route 4096 BGP 2300 VRF Not support ed Not support ed Not support ed Support ed
SCUL
1024
1000
1000
512
128
512
SCUF
5120
4096
4096
5120
4096
4096
SCUN
5120
4096
4096
5120
4096
4096
Principle
The difference between IPv4 routing and IPv6 routing in principle lies in BGP. Specifically, IPv6 supports MP-BGP (and BGP4+), while IPv4 does not support MP-BGP. The following mainly describes MP-BGP. For other principles, see 11.7 Routing. The traditional BGP-4 manages only the IPv4 unicast routing information. The inter-AS transmission of the packets of other network layer protocols (such as, IPv6 and multicast), however, is limited.
12 IPv6
To support multiple types of network layer protocols, the Internet Engineering Task Force (IETF) extends BGP-4 to Multiprotocol Extensions for BGP-4 (MP-BGP). The current MPBGP standard is RFC 4760. MP-BGP is forward compatible. That is, the routers supporting BGP extension can communicate with the routers that do not support BGP extension. As an enhancement of BGP-4, MP-BGP provides routing information for various protocols, such as IPv6 (BGP4+) and multicast. l MP-BGP maintains unicast and multicast routing information, and stores the two types of routing information in different routing tables. This ensures the separation of unicast and multicast routing information. MP-BGP supports unicast and multicast, and constructs different network topologies for them. The unicast routing policy and configurations supported by BGP-4 can mostly be applied to multicast, and thus BGP-4 can maintain unicast and multicast routes according to the routing policy.
l l
Extended Attributes Among packets involved in BGP-4, three IPv4-related attributes are carried by the Update packet: NLRI, Next_Hop, and Aggregator. Aggregator contains the IP address of the BGP speaker that performs route aggregation. To support multiple types of network layer protocols, BGP-4 needs to carry the information about network layer protocols in NLRI and Next_Hop. MP-BGP introduces the following route attributes: l l MP_REACH_NLRI: indicates the multiprotocol reachable NLRI. It is used to advertise a reachable route and the next hop. MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI. It is used to withdraw an unreachable route.
The two attributes are optional non-transitive. Therefore, the BGP speakers that do not support multiprotocol will ignore the information carried by the two attributes, and do not advertise the information to the peers. Address Family BGP uses address families to distinguish different network layer protocols. For the values of address families, refer to RFC 3232 (assigned numbers). The MA5600T/MA5603T supports multiple MP-BGP extension applications, such as VPN extension and IPv6 extension, which are configured in the corresponding address family views.
12.5.2 ACLv6
This section covers unique ACLv6 features as well as its differences from ACLv4, For details about the common features of IPv6 and IPv4, see the specific feature description 10.5 ACL Policy.
Comparison Between ACLv6 and ACLv4

On the MA5600T/MA5603T, the application and configuration processes of ACLv6 are the same as those of ACLv4, except the following differences: l
Issue 01 (2011-10-30)
ACLv4 supports segmented packets, while ACLv6 does not.

12 IPv6
IPv6 and IPv4 have different IP address formats and packet formats, so the ipv6 parameter must be specified for configuring IPv6 basic ACLs and advanced ACLs. Use the ipv6 parameter to choose between IPv4 ACLs and IPv6 ACLs. IPv4 and IPv6 have the same link-layer packet encapsulation format, so configurations do not differentiate IPv6 link-layer ACLs and IPv4 link-layer ACLs. Users define packets matching ACLs based on the packet type. IPv4 and IPv6 have the same packet command for user-defined ACLs, so configurations do not differentiate IPv6 user-defined ACLs and IPv4 user-defined ACLs. When user-defined ACLs are used for filtering packets, the protocol type of the packets must be the same as the protocol type of the ACL rules.
l l
Feature Dependency
For ACLv6, different boards have different restrictions on IPv6 packets: l The SCUB, SCUL, SCUF, and ETHB boards identify only one Next Header field. Regardless of how many headers an IPv6 packet has, these boards match only the Next Header field in the IPv6 header, that is, Next Header marked yellow in Figure 12-9. The SCUN and OPGD boards identify the Next Header field in an IPv6 header and the Next Header field in an IPv6 extension header. When these boards match the Next Header field: If an IPv6 packet has only one header, these boards match the Next Header field in the IPv6 header, for example, Next Header marked yellow in Figure 12-9. If an IPv6 packet has two or more headers, for example, headers marked green, blue, orange, and purple in Figure 12-9, these boards match the Next Header field only in the first extension header, that is, Next Header marked green in Figure 12-9.
Issue 01 (2011-10-30)
402
12 IPv6
Figure 12-9 Format of IPv6 extension headers
Version
Traffic Class
Payload Length
Destination Address Next Header Extension Header Len Extension Head Data Next Header Extension Header Len Extension Head Data Next Header Extension Header Len Extension Head Data
Next Header
Extension Header Len Extension Head Data(last)
Yellow Green Blue Orange Purple
Next Header in the IPv6 header Next Header in the first IPv6 extension header Next Header in the second IPv6 extension header Next Header in the third IPv6 extension header Next Header in the fourth IPv6 extension header
12.5.3 DHCPv6 Relay

DHCPv6 relay functions (in the IPv6 network topology) are similar to DHCPv4 relay functions (in the IPv4 network topology). For details about specifications and principle, see 11.3 DHCP Relay. This topic describes differences between DHCPv6 relay functions and DHCPv4 relay functions.
Specifications
The MA5600T/MA5603T supports the following DHCPv6 relay specifications:
12 IPv6
l l l l l
DHCPv6 Layer 2 and Layer 3 relay Option 18 and option 37 A maximum of 20 DHCPv6 server groups, with 14 DHCPv6 servers in each group Selection of a DHCPv6 server in the DHCPv6 relay standard mode A maximum length of 253 bytes for RID and CID character strings
Reference Standards and Protocols

The DHCPv6 relay feature complies with the following reference standards and protocols: l l l DHCPv6 relay: RFC 3315 (DHCPv6 protocol created by IETF) DHCPv6 Layer 2 relay: draft-ietf-dhc-dhcpv6-ldra-02 (Draft of a DHCPv6 Layer 2 relay protocol created by IETF) DHCPv6 option 37: RFC 4649
Availability
l Only the SCUF and SCUN boards support DHCPv6 Layer 3 relay. Due to the constraints on the routing table specifications, the and SCUB boards do not support IPv6 Layer 3 functions and therefore they do not support DHCPv6 Layer 3 relay. Forwarding of downstream DHCPv6 packets for DHCPv6 Layer 3 relay does not support equal-cost routes. If there are multiple activated equal-cost routes between the MA5600T/ MA5603T and DHCPv6 clients, the MA5600T/MA5603T may send downstream DHCPv6 packets to only one of these routes. DHCPv6 option 38 (that is, DHCPv4 option 82 sub-option 0x81-0x90) is not supported. For DHCPv6 Layer 3 relay, only multicast DHCPv6 packets with the multicast IP address FF02::1:2 can be received.
l l
Principle
The principle of DHCPv6 Layer 2 relay is as follows: 1. When a DHCPv6 relay agent receives a message that needs to be processed using Layer 2 relay, the relay agent constructs a new relay-forward message regardless of the original message type. The relay agent copies the IP address of the original message to the peeraddress field of the new relay-forward message, and copies the entire original DHCP message (excluding the IP header and UDP header) to the relay message option (option 9) of the new relay-forward message. If the original message originates from a DHCPv6 client, the DHCPv6 relay agent initializes the hop-count field of the relay-forward message to 0. If the original message originates from another DHCPv6 relay agent, the relay agent first checks the hop-count field of the message. If the value of the field is greater than 32, the relay agent directly discards the message; if the value is smaller than or equal to 32, the relay agent adds 1 and uses the new value as the value of the hop-count field of the new relay-forward message. The DHCPv6 relay agent invariably sets the link-address field of the relay-forward message to an unspecified address (::) and invariably includes the interface ID option (option 18) and remote ID option (option 37) in the relay-forward message. In the downstream direction, the relay message option (option 9) of the original relay-reply message is extracted, and the content of the relay message option (option 9) is forwarded as a new downstream message to the DHCPv6 client.
2.
3.
4.
Issue 01 (2011-10-30)
12 IPv6
The principle of DHCPv6 Layer 3 relay is as follows: 1. Figure 12-10 only illustrates the forwarding process of DHCPv6 relay. Figure 12-10 Forwarding process of DHCPv6 relay
DHCPv6 client DHCPv6 Relay Agent DHCPv6 server
1. DHCPv6 message from client 2. Relay-forward
3. Relay-reply 4. DHCPv6 message to client
(1) The DHCPv6 client sends a request message to all DHCPv6 servers and relay agents (with the multicast address FF02::1:2). (2) After receiving the request message, the DHCPv6 relay agent encapsulates the message into the relay message option of the relay-forward packet and sends the relayforward packet to the DHCPv6 server. (3) The DHCPv6 server parses the relay-forward packet and obtains the client's request message. Then the server selects the IPv6 address and other parameters for the client, constructs a reply message, encapsulates the reply message into the relay message option of the relay-reply packet, and sends the relay-reply packet to the DHCPv6 relay agent. (4) The DHCPv6 relay agent parses the relay-reply packet, obtains the server's reply message, and then forwards the message to the DHCPv6 client. (5) The DHCPv6 client implements network configuration according to the IPv6 address, IPv6 prefix, and other parameters contained in the reply message. 2. In IPv6, the MA5600T/MA5603T supports selection of the DHCPv6 server group only in the DHCP relay standard mode.
NOTE
A DHCPv6 server allocates both IPv6 addresses and IPv6 prefixes to DHCPv6 clients. After obtaining an IPv6 prefix allocated from the DHCPv6 server, a DHCPv6 client sends a router advertisement (RA) message containing the IPv6 prefix to the network in which it is located. With the prefix, hosts in the network can automatically configure IPv6 addresses.
12.5.4 MAC Address Binding

Anti-MAC spoofing functions (in the IPv6 network topology) are similar to anti-MAC spoofing functions (in the IPv4 network topology). For details about specifications and principle, see 18.9 Anti MAC Spoofing. The procedure for binding MAC addresses dynamically in the IPv6 network topology is different from that in the IPv4 network topology.
12 IPv6
In an IPv6 network, an IPv6 address can be obtained using stateless address autoconfiguration (SLAAC) or DHCPv6. Anti-MAC spoofing can be enabled or disabled globally or based on VLAN. l In a network that uses SLAAC for configuring IPv6 addresses, MAC address binding is triggered by Router Solicitation (RS) and Router Advertisement (RA) packets. The MA5600T/MA5603T captures an RS packet from a CPE, records information such as source MAC address carried in the RS packet, and forwards the RS packet to the network side. The MA5600T/MA5603Talso captures the RA packet, queries the information recorded when processing the RS packet according to the destination MAC address of the RA packet, and binds the MAC address of the CPE to the user port or traffic stream. After that, the MA5600T/MA5603T forwards the RA packet to the CPE. After anti-MAC spoofing is enabled, the MA5600T/MA5603T captures user-side RS packets and network-side RA packets and stops dynamic MAC address learning of the service boards. After anti-MAC spoofing is disabled, the MA5600T/MA5603T stops capturing userside RS packets and network-side RA packets and resumes dynamic MAC address learning of the service boards. The MA5600T/MA5603T also deletes its MAC address binding entries. l In a network that uses DHCPv6 for configuring IPv6 addresses, DHCPv6 packets trigger MAC address binding. The MA5600T/MA5603T obtains DHCP request/solicit/confirm/ renew/rebind/relay-forward packets from the user side and records information such as the source MAC address carried in these packets.
12.5.5 Anti-IP Spoofing

Specifications
Anti-IPv6 spoofing functions (in the IPv6 network topology) are similar to anti-IPv4 spoofing functions (in the IPv4 network topology). For details about specifications and principle, see 18.10 Anti-IP Spoofing. This topic describes differences between anti-IPv6 spoofing functions and anti-IPv4 spoofing functions. Anti-IPv6 spoofing supports the following specifications: l l Static binding: The MA5600T/MA5603T supports a maximum of 8K traffic streams. Each traffic stream can be bound to four IPv6 prefixes. Dynamic binding: Each traffic stream can be bound to a maximum of four IPv6 addresses or prefixes. If a traffic stream is bound to eight IPv4 addresses, this traffic stream can no longer be bound to any IPv6 addresses or prefixes. If bound to four IPv6 addresses or prefixes, this traffic stream can no longer be bound to any IPv4 addresses. If bound to two IPv4 addresses, this traffic stream can still be bound to three IPv6 addresses or prefixes. If bound to four IPv4 addresses, this traffic stream can still be bound to two IPv6 addresses or prefixes. If bound to six IPv4 addresses, this traffic stream can still be bound to one IPv6 addresses or prefixes. The function that anti-IP spoofing does not take effect for IGMP packets cannot be set.
Principle
The procedure for binding IPv6 addresses dynamically is as follows:
12 IPv6
1.
After the dynamic IPv6 address learning function is disabled, the system monitors users' DHCPv6 or SLAAC online and offline processes. When a user goes online, the system dynamically obtains the user's source IPv6 address and binds the user's source IPv6 address to a traffic stream. The system only allows the packets with source IPv6 addresses bound to the user port or traffic stream to pass through. When a user goes offline, the system unbinds the user's source IPv6 address from the traffic stream.
2. 3.
In an IPv6 network, IPv6 addresses can be obtained using SLAAC or DHCPv6. l In a network that uses SLAAC for configuring IPv6 addresses, the broadband network gateway (BNG) assigns IPv6 prefixes to users and the MA5600T/MA5603T dynamically binds these IPv6 prefixes to the user port or traffic stream. Specifically, the MA5600T/ MA5603T obtains IPv6 prefixes assigned to the users from the RA packet sent by the BNG and dynamically generates IP address binding entries. In a network that uses DHCPv6 for configuring IPv6 addresses, DHCPv6 packets trigger IP address binding when a user obtains an IP address using DHCPv6. A DHCPv6 server assigns one or more IPv6 addresses or IPv6 prefixes to a DHCPv6 packet. The MA5600T/ MA5603T obtains all the IPv6 addresses and prefixes assigned by the DHCPv6 server from the DHCPv6 packets received, and then generates IP address binding entries.
In an IPv6 network, the MA5600T/MA5603T supports static binding of IPv6 addresses. The binding of an IPv6 address is different from that of an IPv4 address because of the structure difference between an IPv6 and IPv4 address. In IPv6 binding, the MA5600T/MA5603T binds a length-variable IPv6 prefix to a user port, whereas in IPv4 binding, the MA5600T/ MA5603T binds a complete IPv4 address to a user port.
12.5.6 DAD Proxy

In an IPv6 network, a link-local address (LLA) is generated after the network-side port on a CPE is activated and the CPE performs duplicate address detection (DAD). Before starting DAD, the CPE is added to the multicast group corresponding to the LLA using the Multicast Listener Discovery (MLD) protocol. DAD proxy is implemented on the MA5600T/MA5603T to avoid LLA conflicts.
Definition
In an IPv6 network, a link-local address (LLA) is used for the communication between neighboring nodes on the same link, for example, the communication between hosts on a single link where no routers exist. If an LLA is available, it is automatically used for neighbor discovery. Duplicate address detection (DAD) is a detection mechanism used for determining whether an LLA address is available. A DAD proxy is used to prevent LLA conflicts on a Layer 3 interface.
Purpose
The DAD proxy feature resolves the issue of LLA conflicts between isolated ports on the same Layer 3 interface.
Specifications
The MA5600T/MA5603T supports the following specifications of DAD proxy:
12 IPv6
l l
Enables or disables DAD proxy globally. Supports DAD proxy for user ports and cascading ports.
Availability
The DAD proxy feature is an optional feature of the MA5600T/MA5603T and the feature is controlled by the license.
Principle
In duplicate address detection (DAD) proxy, l When a user performs DAD, the MA5600T/MA5603T checks whether any LLA conflict occurs in the Layer 3 interface VLAN based on the information about the packet sent by the user. If no conflict occurs, the MA5600T/MA5603T forwards the packet. If a conflict occurs, the MA5600T/MA5603T responds to this conflict and drops the packet. l The MA5600T/MA5603T obtains the LLA lease time from Router Advertisement (RA) and DHCPv6 packets, and the buffered LLA entries age when the lease time expires.
12.5.7 ARP/ND Proxy Response

ARP/ND proxy response avoids sending multicast ARP or Neighbor Discovery (ND) packets to irrelevant users, improving system security.
Definition
After ARP/ND proxy response is enabled, the system queries its IP address entries after receiving multicast ARP or ND packets from the network side. If the IP address of such packets exists in the system IP address entries, the system performs proxy response; otherwise, the system drops these packets or broadcasts them in the VLAN according to the configuration on the CLI.
Purpose
ARP/ND proxy response avoids sending multicast ARP or ND packets to irrelevant users, improving system security.
Specifications
The MA5600T/MA5603T supports the following specifications of ARP/ND proxy response. l l l Supports ARP/ND proxy response for a maximum of 16 VLANs. Unicasts or directly forwards packets after proxy response based on VLAN. Drops packets or broadcasts packets in the VLAN when related IP addresses or IPv6 prefixes cannot be found in the system IP address entries.
Availability
l The ARP/ND proxy response feature is an optional feature of the MA5600T/MA5603T and is controlled by a license.
Issue 01 (2011-10-30)
12 IPv6
ARP proxy response and IP-aware are mutually exclusive.
Principle
After receiving a broadcast ARP request from the network side, the MA5600T/MA5603T performs the following operations according to CLI configurations: l If the MA5600T/MA5603T is configured as a proxy to unicast a broadcast ARP request, the MA5600T/MA5603T searches for the IPv4 address of the ARP packet in the system IP address entries. If the address is found, the MA5600T/MA5603T responds to the network side as a proxy and unicasts the ARP packet. If the address is not found, the MA5600T/ MA5603T drops the ARP packet or broadcasts it in the VLAN. Directly broadcasts the ARP packet without any processing by default. Broadcasts the ARP packet if this packet is a gratuitous ARP packet (such a packet is used for address announcement, not for address resolution).
l l
After receiving a multicast Neighbor Solicitation (NS) packet from the network side, the MA5600T/MA5603T performs the following operations according to CLI configurations: l If the MA5600T/MA5603T is configured as a proxy to unicast a multicast NS packet, the MA5600T/MA5603T searches for the IPv6 address of the NS packet in the system IP address entries: If the IPv6 address is found and the user is online, the MA5600T/MA5603T responds to the network side as a proxy and unicasts the NS packet. If the IPv6 address is not found, the MA5600T/MA5603T forwards the NS packet to another network-side or cascading-side port, broadcasts it in the user-side VLAN, or directly drops it. l Directly forwards the NS packet without any processing by default.
12.6 Application
Internet protocol version 6 (IPv6) is developed to deal with the global IPv4 address exhaustion. At the early stage of IPv4-to-IPv6 transition, the predominate IPv4 networks will coexist with the scarcely deployed IPv6 networks. Figure 12-11 shows the IPv6 network deployment at the early stage of IPv4-to-IPv6 transition. Figure 12-11 Early-stage IPv6 network deployment
PE (dual stack) IPv6 IPv6 PC CPE/ONT BRAS (dual stack) 6in4 tunnel
Access Node IPv4 PC IPv4 NATPT
IPv4
Issue 01 (2011-10-30)
409
12 IPv6
An IPv4 broadband remote access server (BRAS) on the live network is upgraded to support IPv4/IPv6 dual stack. The dual-stack BRAS provides a 6in4 tunnel or a private link to transmit IPv6 traffic to an IPv6 network. The dual-stack BRAS provides the network address translation-protocol translation (NAT-PT) function to allow IPv6 users to access an IPv4 network. The access network equipment is able to detect IPv6 packets, assign IPv6 address (DHCPv6 or DHCP Layer 3 relay), and support IPv6 ACL.
12.7 Terms and Abbreviations

Terms
Term IPv6 ND Explanation Internet Protocol Version 6, which is also called IP Next Generation Neighbor discovery, which is used during the forwarding of IPv6 packets for duplicate address detection, neighbor address resolution, and neighbor reachability detection. Additionally, ND is a set of protocols and processes for host address configuration In ND, different ICMPv6 messages are used for router discovery and neighbor discovery. Internet Control Message Protocol Version 6, which is a base protocol of IPv6 and generates error messages and informational messages used by IPv6 nodes to report errors and information generated during packet processing Path MTU, which discovers the supported MTU on a specific path by using ICMPv6 Datagram Too Big messages
ICMPv6
PMTU
Abbreviations
Abbreviation ICMPv6 ND RS RA NS NA ARP PMTU IPv6 IPng
Issue 01 (2011-10-30)
Full Spelling Internet Control Management Protocol Version 6 Neighbor Discovery Router Solicitation Router Advertisement Neighbor Solicitation Neighbor Advertisement Address Resolution Protocol Path MTU Internet Protocol Version 6 IP Next Generation
410
12 IPv6
Abbreviation TCP6 UDP6 RawIP6
Full Spelling Transmission Control Protocol 6 User Datagram Protocol 6 Raw IP6
Issue 01 (2011-10-30)
411
13 Multicast
13
About This Chapter
13.1 Introduction 13.2 Specifications 13.3 Reference Standards and Protocols 13.4 Availability 13.5 Multicast Overview 13.6 Implementation Principle of Multicast 13.7 Advanced Multicast Technologies 13.8 Multicast Fault Diagnosis 13.9 Multicast QoS 13.10 Network Application
Multicast
Multicast is a communication mode in which data is transmitted to multiple recipients at the same time.
Issue 01 (2011-10-30)
412
13 Multicast
13.1 Introduction
Definition
Multicast is a communication mode in which data is transmitted to multiple receivers at the same time.
Purpose
The device employs the multicast technology to provide IP video services, including live TV and QVoD, for carriers. By introducing the multicast technology, the network device can manage, control, and forward IP video services and thus meets carriers' requirements for provisioning IP video service.
13.2 Specifications
Multicast Protocols
The MA5600T/MA5603T supports the following multicast protocol specifications: l l l l l l Supports IGMPv2 Supports IGMPv3 but does not support the Exclude mode Supports IGMP proxy Supports IGMP snooping, including snooping with proxy Supports PIM-SSM Supports VLAN-based multicast (TR101 multicast)
IGMP Performance
The MA5600T/MA5603T supports the following IGMP performance specifications: l l l l Supports distributed IGMP protocol stack (by using the GPON board) Supports two-level multicast duplication mechanism Supports a join latency of 50 ms Supports a leave latency of 50 ms
Multicast Management
The MA5600T/MA5603T supports the following multicast management specifications: l l l l Supports 1024 multicast upstream ports Supports 2048 multicast cascading ports Supports the configuration of 4096 programs (by using the SCUB/SCUF/SCUL/SCUN board) or 1024 programs (by using the SCUA board) Supports concurrent forwarding of 2000 programs (by using the SCUF/SCUN board) or 1024 programs (by using other control boards)
Issue 01 (2011-10-30)
13 Multicast
Supports 8192 GPON users, or supports 1024 xDSL, or OPFA users; supports a maximum of 8192 users when these boards are used together; supports 2048 users (by using each GPON board) Supports 2000 rights profiles Supports a maximum of 64 rights profiles bound to each user Supports a maximum of 32 different programs watched by each user at the same time Supports 32 preview profiles Supports multicast bandwidth CAC for a maximum of 128 PON ports Supports multicast CDR Supports IGMP message statistics measurement Supports the query of multicast program traffic Supports remote acceptance for the multicast service of the xDSL and OPFA boards Supports a maximum of 16 IP address segments for dynamic programs in an MVLAN Supports automatic recording of multicast users' online and offline logs (SCUA: 10240 records; SCUB/SCUL/SCUN: 32768 records) Supports multiple MVLANs switching to different C-VLANs for ONTs Supports S+G (source IP address+multicast IP address) forwarding for the multicast service
l l l l l l l l l l l l l
Multicast Networking
The MA5600T/MA5603T supports the following multicast networking specifications: l l l l Supports aggregation and protection on multicast upstream ports and multicast cascading ports Supports double VLAN tags on multicast upstream ports Supports GPON Type B for multicast users Supports PIM-SSM cascading (only by using GIU board)

The reference standards and protocols of this feature are as follows: l l l l l l TR101: Technical Report DSL Forum, TR-101 Migration to Ethernet-Based DSL Aggregation, April 2006 TR156: Technical Report Broadband Forum, TR-156 Using GPON Access in the context of TR-101, December 2008 RFC 1112 : Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989 RFC-2236: Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997 RFC 3376: B. Cain., "Internet Group Management Protocol, Version 3 ", RFC 3376,October 2002 RFC 3569: S. Bhattacharyya, "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003
Issue 01 (2011-10-30)
13 Multicast
l l l l l
RFC 4601: B. Fenner, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC4601, August 2006 RFC 4604: H. Holbrook, "Using IGMPv3 and MLDv2 for Source-Specific Multicast", RFC 4604, August 2006 RFC 4605: B. Fenner, "IGMP/MLD Proxying", RFC 4605, August 2006 RFC 4607: H. Holbrook, "Source-Specific Multicast for IP", RFC 4607, August 2006 RFC 4541: M. Christensen, "Considerations for IGMP and MLD Snooping Switches", RFC 4541, May 2006
13.4 Availability
Hardware Support
No additional hardware is required for supporting this feature.
License Support
l The number of the multicast users supported by the device is controlled by license. The permitted number of multicast users can be configured only after the corresponding license is obtained. The number of multicast programs that can be configured or demanded by the multicast users of the device is controlled by license. The permitted number of multicast programs can be configured or demanded only after the corresponding license is obtained. The device can be controlled through license only by either of the two methods described above.
Version Support
13.5 Multicast Overview

Differences Between Multicast and Unicast
There are three basic forms of network transmission: unicast, broadcast, and multicast. Unicast: a point-to-point (P2P) transmission mechanism. Unicast involves only one information sender and one information recipient.
Issue 01 (2011-10-30)
415
13 Multicast
Figure 13-1 Unicast

User A
Source User B
User C
A B C
Broadcast: a point-to-all-point transmission mechanism. Broadcast involves only one information sender and all the reachable information recipients in a LAN. Figure 13-2 Broadcast
User A Source User B
User C
User D Broadcast information
Multicast: a point-to-multipoint (P2MP) transmission mechanism. Multicast involves only one information sender and multiple information recipients that are interested in the multicast address.
Issue 01 (2011-10-30)
416
13 Multicast
Figure 13-3 Multicast

User A of group 1 Source User B of group 1
User C of group 2
User D of group 2
Multicast information about group 1 Multicast information about group 2
According to the preceding definitions: l In the multicast mode, a single data stream is sent to a group of users at the same time. Only one copy of the same multicast data stream exists on each link. Compared with the unicast mode, in the multicast mode, the increase of users does not immediately increase the load of the network. Hence, the server and the CPU can deal with a lighter load. Multicast messages can be sent across different network segments and will not be received by users who are not interested in the messages. Compared with the broadcast mode, the multicast mode achieves a longer information transmission distance and ensures that information is transmitted to only interested recipients. Hence, information security can be guaranteed.
The preceding comparisons show that multicast effectively resolves the problem of P2MP transmission and implements efficient P2MP data transmission in IP networks.
Multicast Terms
l Multicast group A multicast group is identified by a multicast IP address. Any host (or any other receiving device) joining a multicast group becomes a member of the group. The group member can identify and receive the IP messages destined to the multicast IP address. l Multicast source
A signal source sending IP messages destined to a multicast address is called a multicast source. A multicast source can send data to multiple multicast groups at the same time. l Multicast group member
The members of a multicast group are dynamic. Hosts in a network can join or leave a multicast group any time. Multicast group members may be widely dispersed across the network. A multicast source is usually not a data recipient at the same time and is not the member of a multicast group. l Multicast duplication
Multicast duplication is a capability with which the network device duplicates a multicast message from an ingress port into multiple copies and sends them to multiple egress ports. To
13 Multicast
ensure effective transmission of multitudes of data, this function can be implemented only by hardware. The following provides an example of watching the program of a TV channel to aid the understanding of relevant concepts of IP multicast. l l l The multicast group is an agreement between the sender and the recipient. For example, a TV channel can be regarded as a multicast group. The TV station is the multicast source and it sends data to a certain TV channel. The TV set is a receiving host. When the user turns on the TV and chooses to watch the program of a channel, this action can be regarded as the host joining a multicast group. Then, the TV set displays the program of the TV channel to the user, which means that the host has received the data sent to this multicast group. The user can turn on or turn off the TV set or switch between channels any time, which means that the host can join or leave a multicast group dynamically.
Multicast Address
To enable the communication between a multicast source and its members, a network-layer multicast address must be available, which is the multicast IP address. In addition, a technology must also be available for mapping the multicast IP address to a link-layer multicast MAC address. The following part of this section will describe the two types of multicast address. l Multicast IP address
As specified by Internet Assigned Numbers Authority (IANA), multicast messages use class-D IP addresses (224.0.0.0-239.255.255.255) as their destination addresses, and the class-D IP addresses must not appear in the source IP address field of the IP messages. Address segment 224.0.0.0-224.0.0.255 is reserved for the network protocols in the local network. Address segment 239.0.0.0-239.255.255.255 is for management addresses. The purpose of defining management addresses is to limit the multicast addresses within specified multicast domains so that the addresses of different domains can be re-used. Multicast addresses are not allocated to the receiving device or the multicast source device for identifying their network location. In the case of the multicast source device, the allocated multicast address is used for generating and carrying multicast data; in the case of the receiving device, the multicast address is used for distinguishing multicast data. In an actual multicast application, the multicast address usually need not be manually input. For example, in the live TV service, which is a common application, a menu interface is provided. When the user demands a program by using a remote controller, the application software will automatically obtain the multicast IP address corresponding to the program. l Ethernet multicast MAC address
When IP messages are unicast over an Ethernet, the destination MAC addresses used are the MAC addresses of recipients. However, in the transmission of multicast messages, the transmission destination is no longer a specific recipient. Instead, it is a group with uncertain members. In this case, the multicast MAC address is used. Specified by IANA, the most significant 25 bits of a multicast MAC address are 0x01005e, and the least significant 23 bits of the MAC address are the least significant 23 bits of the multicast IP address. The following figure shows the mapping.
13 Multicast
Figure 13-4 Mapping between multicast MAC address and multicast IP address
XXXX X 32-bit IP address 1110 XXXX
5 bits lost X XXXXXXX XXXXXXXX 23 bits mapping XXXXXXXX XXXXXXXX
48-bit MAC address 00000001 00000000 01011110 0 XXXXXXX
XXXXXXXX
Prefix of the 25-bit MAC address
The first four bits of the multicast IP address are 1110, which stands for the multicast ID, and in the last 28 bits, only 23 bits are mapped to the MAC address. Thus five bits of information in the IP address is lost. The direct result is that 32 multicast IP addresses are mapped to the same MAC address.
Multicast Service
Multicast is an end-to-end service. The implementation of a multicast application needs to be accomplished by various devices in the network playing respective roles. The following figure shows the multicast service. Figure 13-5 Multicast service
TV Modem AN Multicast router Multicast router Multicast source
Multicast application . . . Group member protocol Group member protocol
Multicast application Multicast routing protocol Group member protocol Multicast routing protocol
Group member protocol: usually applied between a router and a host. The group member protocol allows the host to dynamically join or leave a multicast group and implements multicast member management. Multicast routing protocol: usually applied between routers. The multicast routing protocol is used for generating a message distribution tree for multicast routing. Messages are then transmitted from the multicast source to recipients through the routes.
13 Multicast
Multicast application: multicast application software, such as video application software, based on the TCP/IP protocol stack and used by the multicast source and recipients. The channel switching includes two protocol actions: sending a message to leave the existing multicast group, and at the same time sending a message to join a new multicast group.
IGMP Protocol
The Internet Group Management Protocol (IGMP) is used for maintaining the multicast group membership between a host and a router. There are currently three IGMP versions, namely, IGMPv1, IGMPv2 and IGMPv3. The later version is completely compatible with the earlier version(s). IGMPv1 is now rarely supported by systems. Therefore, according to TR101, the device no longer supports IGMPv1. IGMPv1 messages are dropped. This section considers IGMPv2 as an example to describe the main contents of the protocol. IGMP messages Role Router Message Type General query Description A router periodically sends this message to maintain the requirements posed by all hosts connected to the router on all multicast groups. The router detects an accidentally offline host by an aging mechanism. A router sends this message to check whether a multicast group is still required by any host. The router usually sends this message when receiving a leave message. The report message is used by a host for actively joining a multicast group or for responding to a general query or a group-specific query. The leave message is used by a host for actively informing a router that the host no longer needs a multicast group.
Group-specific query Host Report
Leave
IGMPv3 includes the basic concepts of IGMPv2. For details, see "IGMPv3".
13.6 Implementation Principle of Multicast

13.6.1 Basic Managed Objects
Basic multicast managed objects refer to the fundamental managed elements of multicast. In other words, they are the necessary configured objects for provisioning the multicast service in a single MVLAN of the device.
Multicast VLAN
A multicast VLAN (also called an MVLAN) refers to the VLAN tag carried by multicast data. MVLANs are usually divided based on ISP. By the implementation of the forwarding plane, control plane, and management plane based on VLAN instance, multicast services are provisioned to the users of the same device, allowing the users not to be interfered by each other.
13 Multicast
Except the super VLAN, the VLAN of any attribute or any type configured on the device can serve as an MVLAN. For details on the MVLAN, see "Multi-instance Multicast".
Multicast Program
A multicast program can be regarded as a multicast group. Its basic attribute is the multicast IP address. The device can manage a multicast program at a finer grain, such as by rights control and CAC. According to whether the attributes (such as the multicast IP address) of each program are configured before the service is provisioned, multicast programs can be classified into two types: pre-configured programs and dynamic programs. For details on dynamic programs, see "Dynamic Program".
Multicast Upstream Port

A multicast upstream port is one through which a multicast source connects to the device, and is also a port through which an upper-layer multicast router connects to the device. According to their dependency on the link-layer loop protocol, multicast upstream ports can be classified into two types: manually configured (static) upstream ports and dynamic upstream ports. For details on dynamic upstream ports, see "Ring Network of Upstream Ports".
Multicast User
A multicast user is a multicast data recipient. A service stream must be configured for the multicast user for carrying multicast control messages in the upstream direction (the device can distinguish the user by traffic classification). Therefore, a multicast user corresponds to a unique terminal or service subscriber. Meanwhile, an MVLAN must be specified for the multicast user to indicate to which ISP the service subscriber belongs. The following figure shows the relationships between the basic managed objects. Figure 13-6 Multicast managed objects
TV STB Modem AN ISP
TV
STB Multicast upstream port Multicast program Program 1 Program 2 MVLAN
Terminal ...
Multicast user ...
MVLAN
. . .
Program N
Issue 01 (2011-10-30)
421

NOTE
13 Multicast
l As a device placed at users' home, an ONT does not support multiple multicast users. Although the ONT is for only one multicast user, it can still connect to multiple STBs. l Traffic streams with the QinQ attribute do not support multicast users. l Traffic streams that adopt traffic classification by double VLANs do not support multicast users.
13.6.2 Forwarding Framework on the Device

This section describes the framework of the hardware forwarding plane for multicast.
Multicast Forwarding Table [OLT]

Figure 13-7 Multicast forwarding table
OLT
Service board
. . TV ONT Splitter Service board .
Control board
First-level forwarding table Index VLAN+ GMAC Duplication Destination GPON port list Duplication Destination Service board list
Third-level forwarding table Index VLAN+ GMAC Duplication Destination ONT port list
Second-level forwarding table Index VLAN+ GMAC
The OLT supports a distributed 2+1-level duplication architecture. The first-level duplication is implemented on the control board. By using the "VLAN+GMAC" index, the control board duplicates multicast data to the service board interested in the multicast program in an as-perrequirement manner, thus effectively saving the backplane bandwidth. The second-level duplication is implemented on the service board. By using the "VLAN+GMAC" index, the service board duplicates multicast data to the GPON port interested in the multicast program in an as-per-requirement manner, thus effectively saving the downstream bandwidth of the GPON port. Then the service board encapsulates and transmits the multicast data on the GPON port in the mode of multicast GEM port (system-level parameter, configurable, the default value is 4095). The third-level duplication is implemented on the ONT. By using the "VLAN+GMAC" white list, the ONT filters out unneeded multicast data to avoid bandwidth overflow at the downstream ingress (ONT only supports that in olt-control mode). Then, by using the "VLAN
13 Multicast
+GMAC" index, the ONT duplicates the multicast data to the ONT ports in an as-perrequirement manner (only supports forwarding by using GMAC in snooping mode). This section describes only the forwarding framework in the most common single-copy duplication mechanism. For the hardware forwarding framework in the multi-copy duplication mechanism, see "GPON Multi-Copy Duplication".
Multicast Forwarding Table [DSLAM]

Figure 13-8 Multicast forwarding table
Service board
. . TV Modem . Service board
Control board
First-level forwarding table Index Second-level forwarding table Index VLAN+ GMAC Duplication Destination Port list VLAN+ GMAC Duplication Destination Service board list
The DSLAM supports a distributed two-level duplication architecture. The first-level duplication is implemented on the control board. By using the "VLAN+GMAC" index, the control board duplicates multicast data to the service board interested in the multicast program in an as-per-requirement manner, thus effectively saving the backplane bandwidth. The secondlevel duplication is implemented on the service board. By using the "VLAN+GMAC" index, the service board duplicates multicast data to the multicast user (usually corresponding to the first port) interested in the multicast program in an as-per-requirement manner.
13.6.3 IGMP Control Framework

This section describes the control plane framework of IGMP messages. IGMP proxy is considered as an example.
Issue 01 (2011-10-30)
423
13 Multicast
IGMP Proxy
IGMP proxy is a mode in which the device in a tree topology does not set up a route to forward multicast messages, but only acts as a proxy for multicast protocol messages. Details are as follows: l From the perspective of a terminal, the device serves as a multicast router that implements the functions of the router in the IGMP protocol. Specifically, the device fixedly functions as an IGMP querier (not supporting querier election for security concerns) on the user-side network. The device receives and terminates the join and leave messages of all multicast users, and duplicates the multicast program to only the interested multicast users according to the maintained group membership table.
Table 13-2 Structure of the group membership table Index VLAN+GIP Online Member Multicast user list (such as multicast user 1 and multicast user 2)
From the perspective of a multicast router, the device serves as a multicast group member that implements the functions of the host in the IGMP protocol. According to the changes (addition or deletion) of the record in the group membership table, the device sends the join message or leave message of a program to the upper layer through the multicast upstream port. In addition, the device responds to the queries of the multicast router according to the status of the group membership table.
Therefore, IGMP proxy effectively reduces the quantity of IGMP messages exchanged on the network side and thus lessens the load of multicast routers. It is configurable on the device whether to send the IGMP general query to all multicast users or to only interested multicast users.
Distributed IGMP [OLT]

Figure 13-9 Distributed protocol model
OLT
IGMP ONT H R
IGMP
R represents the router functions of the IGMP protocol, and H represents the host functions of the IGMP protocol. In the distributed two-level IGMP protocol stack, the first level is on the control board and the operation on the user side and the network side is based on MVLAN; the second level is on the
Service board
Control board
13 Multicast
service board, the operation on the network side is based on MVLAN, and the operation on the user side is based on multicast user, which ensures that users do not affect each other on the control plane. The convergence of the IGMP protocol stack on the service board lightens the processing load of the IGMP protocol stack on the control board. Given the same hardware conditions, the system can process channel switching of more multicast users at the same time.
Architecture of the IGMP Protocol Stack [DSLAM]

Figure 13-10 Architecture of the IGMP protocol stack
IGMP Modem H Service borad R Control H board R
R represents the router functions of the IGMP protocol, and H represents the host functions of the IGMP protocol. In the architecture of the IGMP protocol stack, the operation on the control board and the network side is based on MVLAN, and the operation on the user side is based on multicast user (to ensure that the control planes of the users do not interfere with each other).
13.6.4 Multicast Forwarding Flow

This section considers IGMPv2 proxy as an example to describe the general multicast forwarding flow based on the management plane, control plane, and forwarding plane.
Join Flow [OLT]

Figure 13-11 Join flow
OLT
Service board Multicast 5 Multicast program router Control board 4 Join message
o in e 3 J sa g s me
. . TV ONT . Splitter Service board 1 VOD 2 Join message
Issue 01 (2011-10-30)
425
13 Multicast
1. 2.
The multicast user switches a channel and sends a join message for demanding a new program GIP1. After receiving the join message, the service board enters the IGMP protocol stack of the multicast user. After multicast control is implemented (for details, see "Multicast CAC"), the following group membership table is generated on the service board. Index MVLAN1+GIP1 Online Member Multicast user 1
l At the same time, the following multicast forwarding table is generated on the service board (for details on how to map GIP1 to GMAC1, see "Multicast Address"). Index MVLAN1+ GMAC1 Duplication Destination GPON port 1
l According to MVLAN1 corresponding to the program, the service board serves as the proxy of multicast user 1 and sends a join message to the control board. 3. After receiving the join message, the control board enters the IGMP protocol stack of MVLAN1 and generates the following group membership table. Index MVLAN1+GIP1 Online Member Service board 1
l At the same time, the control board generates the following multicast forwarding table. Index MVLAN1+ GMAC1 4. 5. Duplication Destination Port corresponding to service board 1
The control board then sends a join message to the multicast router through the multicast upstream port of MVLAN1. After receiving the multicast stream, the device first duplicates the stream to service board 1 according to the multicast forwarding table of the control board, and then duplicates the stream to GPON port 1 according to the multicast forwarding table of the service board.
NOTE
Though the SVLAN of a multicast user is different from the MVLAN, the device can still implement the mapping to the MVLAN according to the multicast member configuration relationship. In this way, crossVLAN multicast is supported without requiring additional configuration.
Issue 01 (2011-10-30)
426
13 Multicast
Join Flow [DSLAM]

Figure 13-12 Join flow
Service board 4. Multicast program Control board 3. Join message Multicast router
. . TV Modem . Service board 1. VoD
in Jo 2 . sa g e s me
1. 2.
The multicast user switches a channel and sends a join message for demanding a new program GIP1. After receiving the join message, the control board enters the IGMP protocol stack of the multicast user. After multicast control is implemented (for details, see "Multicast CAC"), the following group membership table is generated on the control board. Index MVLAN1+GIP1 Online Member Multicast user 1
l At the same time, the following multicast forwarding tables are generated on the control board and the service board (for details on how to map GIP1 to GMAC1, see "Multicast Address"). l Multicast forwarding table on the control board Index MVLAN1+ GMAC1 Duplication Destination Corresponding port on service board 1
l Multicast forwarding table on the service board Index MVLAN1+ GMAC1 Duplication Destination User port 1
Issue 01 (2011-10-30)
427
13 Multicast
l According to MVLAN1 corresponding to the program, the service board serves as the proxy of multicast user 1 and sends a join message to the control board. 3. 4. The control board then sends a join message to the multicast router through the multicast upstream port of MVLAN1. After receiving the multicast stream, the device first duplicates the stream to service board 1 according to the multicast forwarding table of the control board, and then duplicates the stream to user port 1 according to the multicast forwarding table of the service board.
NOTE
Though the SVLAN of a multicast user is different from the MVLAN, the device can still implement the mapping to the MVLAN according to the multicast member configuration relationship. In this way, crossVLAN multicast is supported without requiring additional configuration.
Leave Flow
The processing flow of the leave message is the same as that of the join message except that the actions involved are different. For details, see "Fast Leave".
Query Flow
According to IGMP, the status of multicast users needs to be maintained through general queries. This avoids the situation where an entry is not deleted after a multicast user leaves "quietly". Therefore, the service board sends general queries to all multicast users at preset query intervals. To save the resources occupied, it is configurable that the service board queries only online multicast users. If the service board does not receive a report message from a multicast user within the preset aging time (robustness variable x query interval + maximum response time), the service board deletes the corresponding entry of the multicast user from both the multicast relationship table and the multicast forwarding table. The group-specific query message follows a similar transmission flow.
Query Flow of the Multicast Router

After the device receives the general query message from the multicast router, the control board first consults the group membership table to check whether any online service board exists in the corresponding MVLAN. If yes, the control board serves as the proxy of this service board and sends a report message as a response to the multicast router. The group-specific query message follows a similar processing flow.
13.7 Advanced Multicast Technologies

13.7.1 Multicast Service
Multi-instance Multicast
With the increased use of open networks, carriers' networks need to provide independent multicast domains for different multicast ISPs so that different ISPs do not interfere with each other. Independent multicast domains can be implemented on the management plane, control plane, and forwarding plane by planning different MVLANs on the device. l
Issue 01 (2011-10-30)
Management plane
13 Multicast
Within each MVLAN, the multicast programs to be provisioned, and the multicast upstream ports and multicast users involved can be configured for each ISP. Here, the multicast programs need to be noted. To ensure that each ISP can plan multicast programs independently, the multicast program triplet (MVLAN, source IP address, and multicast IP address) needs to observe the following rules: If two GIPs are mapped to the same GMAC (for details on the mapping method, see "Multicast Address"), the two GIPs are regarded as the same GIP. To ensure the uniqueness of a multicast forwarding entry on the forwarding plane, (MVLAN, multicast IP address) must be unique. Especially, in the case of an IGMPv2 message or an IGMPv3 message in the ASM mode, the multicast source IP address equals any value (usually represented as * or as any). In this case, only the second rule needs to be observed. Consider section G in the following figure as an example. According to the second rule, (MVLAN, multicast IP address) must be unique, but (VLAN1, G1) in section G is not unique. Therefore, configuring or generating the entries in section G is not allowed. The entries in the other sections in the following figure can also be judged by the rules described above. Figure 13-13 Triplets of multicast programs
Common triplet (VLAN1, S1, G1) (VLAN1, S1, G2) (VLAN1, S1, G3) Optional triplet (VLAN1, S1, G1) (VLAN1, S2, G2) (VLAN1, *, G3) Forbidden triplet (VLAN1, S1, G1) (VLAN1, S2, G1) (VLAN1, *, G1)
(VLAN1, S1, G1) (VLAN2, S2, G1) (VLAN3, *, G1)
(VLAN1, S1, G1) (VLAN2, S1, G2) (VLAN3, S1, G3)
(VLAN1, S1, G1) (VLAN2, S2, G2) (VLAN3, *, G3)
(VLAN1, (VLAN2, (VLAN3,
*, G1) *, G1) *, G1)
S: source IP address G: group IP address
Control plane On the network side, each MVLAN has an independent IGMP protocol stack. Each ISP can select the protocol version, message priority, and IGMP proxy or IGMP snooping. On the user side, each multicast user has an independent IGMP protocol stack and is not affected by other multicast users.
Forwarding plane On the forwarding plane, all multicast forwarding tables use MVLAN and multicast MAC address as indexes. This ensures that different MVLANs do not interfere with each other. For details, see "Multicast Forwarding Table." For the control board, implementing QoS scheduling on the traffic of different MVLANs on the same port on the service board equals unicasting. For details, see "QoS."
Issue 01 (2011-10-30)
429
13 Multicast
CAUTION
1. In most situations, the MVLAN is different from the S-VLAN of the traffic stream to which the multicast user belongs. This S-VLAN can be used in the IPTV VoD service. 2. VLANs in S-VLAN+C-VLAN forwarding mode are used for transmission over point-topoint channels and are not applicable to multicast duplication and forwarding. Therefore, the S-VLAN in S-VLAN+C-VLAN forwarding mode cannot be used as an MVLAN.
Dynamic Program
In actual applications, if fine-grained management is not required on the device, dynamic programs can be applied. This avoids maintenance troubles brought by frequent program changes. In this case, program maintenance can be performed uniformly through the Electronic Program Guide (EPG) system. Figure 13-14 Flow of generating dynamic programs
AN TV STB Modem ISP EPG Multicast source Program 1 Program 2 . . . Program N 1. STB obtains program menu from EPG. Program 1 Program 2 . . . Program N
2. STB demands programs. 3. Multicast source issues programs.
1. 2.
After being started, the STB automatically obtains the program menu from the EPG server and provides the menu for the multicast user. When the user orders a program, a corresponding IGMP message is generated and sent to the device. Hence, the program information on the device at this stage is not input by the administrator. Instead, it is dynamically generated in the MVLAN (to which the multicast user belongs) after the multicast group IP address and source IP address are extracted by the device from the real-time IGMP message of the multicast user. The multicast program of the multicast source reaches the STB. To prevent the user from using an inappropriate group IP address, a legal multicast address segment can be configured based on MVLAN on the device for dynamic programs. According to the configuration, a multicast program is generated only when the group IP address is within the legal address segment; otherwise, the IGMP message of the user is dropped. Apart from the restriction by the address segment, the number of programs that can be dynamically generated is also controlled by hardware specifications and license.
3.
Issue 01 (2011-10-30)
430
13 Multicast
The fine-grained management that is not supported by dynamic programs on the device includes CAC, rights management, multicast preview, and pre-join.
Rights Management
With the method of configuring different multicast programs on different profiles, packagebased rights management can be implemented on the device. l Rights profile The rights to any multicast program can be specified in each rights profile, and each rights profile can be configured with a meaningful name. There are four types of rights: Forbidden: It indicates that a multicast user is not allowed to watch or preview a multicast program. Preview: It indicates that a multicast user can order a multicast program but is restricted in the watching duration and watching times. Watch: It indicates that a multicast user can order a multicast program normally without any restriction. Idle: It indicates that a specific right is not assigned to a multicast program yet. It is the default value of the rights profile. The effect of "idle" equals that of "forbidden." Carriers can plan the rights profiles according to user-defined rules. Usually, there are three modes of planning. The first one is planning by contents, such as planned as the news type, sports type, and movie type. In this case, one multicast program belongs to only one rights profile and the programs of different profiles do not overlap. Therefore, one user is usually bound to multiple profiles. See the following figure. Figure 13-15 Planning rights profiles-mode 1
Program 1 ... Program N Program N+1 ... Program M Program M+1 ... Program X Movie type User 3 News type Sports type Movie type Sports type User 2 Movie type News type User 1 News type Sports type
The second one is planning different levels by content volumes, such as planned as the basic type, family type, and adult type. In this case, one multicast program may belong to multiple rights profiles and the programs of different profiles may overlap. Therefore, one user is usually bound to only one profile. See the following figure.
Issue 01 (2011-10-30)
431
13 Multicast
Figure 13-16 Planning rights profiles-mode 2
Basic type
User 1
Basic type
Program group A Program group B Program group C
Family type
User 2
Family type
Adult type
User 3
Adult type
The third one is a hybrid of the first and second ones and is the most complicated as well as the most flexible mode. In this mode, the programs of different rights profiles may overlap and one user may be bound to multiple profiles. The same program may be configured with different rights in different rights profiles. To ensure that these rights profiles work as expected by the carrier when it comes to a specific program for a specific user, the rights of a program in the rights profiles must be prioritized. It is recommended to plan the priorities before deployment to prevent any incorrect results. The following are examples. Table 13-3 Priority of rights: forbidden > preview > watch > idle Rights profile 1 Rights profile 2 Program 1: watch Program 1: forbidden User 1 Program 1: forbidden
Table 13-4 Priority of rights: watch > preview > forbidden > idle Rights profile 1 Rights profile 2 Program 1: watch Program 1: forbidden User 1 Program 1: watch
Rights control The rights of each multicast user can be configured by the following two steps: 1. 2. Plan the rights profiles of all multicast programs. Bind a multicast user to the rights profiles required according to the contents subscribed to by the user. The device provides open MIB interfaces to support such operations. In addition, there is another method of implementing rights control: by configuring encryption on the head system and the STB. In this way, the carrier does not need to
Issue 01 (2011-10-30)
432
13 Multicast
perform rights management on the device and only needs to enable or disable rights control at the system level or the multicast user level.
Multicast Preview
By providing the preview of certain special channels to multicast users, carriers may attract more users to subscribe to more programs with the watch right. Preview is usually used as an effective selling method. The device manages the preview parameters of each multicast program by preview profiles. To be specific, each multicast program can be bound to a preview profile which is configured with preview parameters. Similar programs can be bound to the same preview profile to simplify management. A preview profile contains three preview parameters. Figure 13-17 Preview parameters
Program Preview duration Program N T1 T2 T3 Time T1: Start time of first preview T2: End time of first preview T3: Start time of second preview Preview interval
Preview interval: It is the minimum interval between two previews. The interval is from the end time of the previous preview to the start time of the current preview (from T2 to T3 as shown in the preceding figure). If the interval between the two previews of a user does not reach the specified preview interval, the user is currently not allowed to preview the program. Such a mechanism guards against any "rogue" behavior of users. Without the restriction of the preview interval, a user may keep previewing the same program and is actually "watching" a program without having to pay for the "watch" right. Preview times: This parameter specifies how many times a multicast user is allowed to preview the same program during a day. Each time the user leaves a previewed program, the counter increases by 1. When the counter exceeds the maximum value, the further orders of the user for the program will be rejected. In this case, the user's right to the program can be regarded as demoted to "forbidden." However, the preview right can recover the next day. Preview duration: This parameter specifies for how long a multicast user is allowed to watch the same program each time. The duration starts from the beginning of the order (from T1 to T2 as shown in the preceding figure). After the duration expires, the user will not be able to receive any data for the multicast program.
For details on how to control the preview of multicast users, see "Rights Management."

NOTE
13 Multicast
The boards with centralized multicast services do not support active/standby synchronization of preview data, but the boards with distributed multicast services support so.
Multicast CAC
CAC is the short form for call admission control. Here, it means controlling the setup of IGMP sessions. If an IGMP session fails to be set up, a multicast user will fail to receive the multicast program ordered. In a broad sense, implementing CAC requires implementing the first-level control in the system. Currently, system control includes the following: l Anti-DoS attack. The rate of IGMP messages sent from the user side must not exceed the specified value in the system. Otherwise, the system will regard that a DoS attack occurs and drops the messages. Such a protection method applies not only to IGMP messages, but also to control packets such as DHCP and PPPoE packets. For details, see "Anti-DoS Attack." Anti-IP spoofing. When this function is enabled, the user must obtain a legal IP address through DHCP before ordering any program. Only the IGMP messages using the legal IP address as their source IP address will be accepted by the system; otherwise, the messages will be regarded as coming from unauthorized users and will be dropped by the system. For details, see "Anti-IP Spoofing."
NOTE
Only the centrally-controlled multicast supports this feature.
Broadband message overload. When a service traffic burst occurs, the system resources may not be able to support all services. Then, the system will drop certain messages according to specified policies to ensure that the services with a higher priority are not affected. In this case, IGMP messages may be "sacrificed" to reduce the system load. For details, see "Broadband Message Overload." After the first-level control in the system comes the multicast first-level control, which includes the following:
Concurrent number of programs of a multicast user. This parameter specifies how many channels a multicast user is allowed to order at the same time. The parameter can be configured based on multicast user. Rights control. For details, see "Rights Management." Bandwidth check. Though the system supports QoS control on various types of traffic, packet loss (drop by priority or tail drop) may still occur when the transmission bandwidth is overloaded. However, due to the real-time and non-retransmittable properties of multicast programs, postmortem QoS will directly cause pixelation to the programs with packet loss (not only to newly ordered programs). Hence, the requirements of IPTV for high-quality experience are not met. Bandwidth check enables the system to control a newly ordered program beforehand. In this way, the system can ensure that the programs that have been ordered enjoy sufficient bandwidth and will not be affected by the new program. With bandwidth check, only the newly ordered program is affected (if bandwidth is insufficient, the user will not be able to watch the newly ordered program).
l l
CAC can be classified into three types according to different control points and methods. l Multicast user bandwidth CAC First, each pre-configured program is configured with bandwidth. The bandwidth is configured with reference to the video bit streams, and the margin of packet encapsulation
13 Multicast
and network transmission jitter; if possible, actually tested network traffic can also be used, as a better reference. Then, each multicast user is configured with available bandwidth. The available bandwidth is configured with reference to the actual line bandwidth or the planning of service provisioning. Hence, when receiving the first IGMP join message of a program, the device subtracts the bandwidth occupied by the program from the available bandwidth of the user. If the remainder is smaller than 0, the device rejects the order request of the user. When receiving an IGMP leave message of a program, the device returns the bandwidth occupied by the program to the available bandwidth of the user. The time of returning is the time when the device stops forwarding multicast data. That is, the program is not ordered by any end user of the terminal. For details, see "Fast Leave." Figure 13-18 Multicast user bandwidth CAC
Multicast bandwidth Maximum available bandwidth Bandwidth of program 1 0 Join program 1 Leave program 1 Join program 1 Join program 2 Multicast bandwidth Maximum available bandwidth Bandwidth of Bandwidth of program 2 program 1
Programs that can be watched Programs that cannot be watched
Multicast user bandwidth CAC can be configured at the system level or at the multicast user level. l GPON port bandwidth CAC [OLT] GPON single-copy duplication function (default configuration): Under the same GPON port, even if multiple multicast users order the same multicast program, the multicast data is duplicated only once and sent to corresponding multicast users through the downstream multicast channel. Therefore, this function ensures that the downstream multicast bandwidth does not overflow the downstream line bandwidth of the GPON port. To do so, the operator first needs to configure bandwidth for each pre-configured program (see "Multicast user bandwidth CAC"), and then allocates the available bandwidth for each GPON port (depending on the actual line bandwidth or the service provisioning plan). In this way, after receiving the first IGMP join message of the program, the device deducts the bandwidth of the corresponding program from the remaining bandwidth of the GPON port. If the deduction result is smaller than 0, the device rejects the order of the user. After receiving an IGMP leave message, the device returns the bandwidth of the corresponding program to the GPON port (the moment of returning is when the forwarding of multicast data is stopped, that is, no multicast user under the GPON port orders this program). GPON multi-copy duplication (see "GPON Multi-Copy Duplication"): Because the duplication of multicast programs is based on multicast user, the bandwidth control is also based on multicast user-based on the join and leave of each multicast user. The following figure shows the differences between single-copy duplication and multi-copy duplication.
Issue 01 (2011-10-30)
435
13 Multicast
Figure 13-19 GPON port bandwidth CAC

GPON port bandwidth Maximum bandwidth Program 1 bandwidth 0 User 1 joins User 2 joins User 3 joins program 1 program 1 program 1 Single-copy
GPON port bandwidth Maximum bandwidth 1 Program 1 bandwidth 1 Program 1 bandwidth
Multi-copy
1 1 User 1 joins program 1
2 1 User 2 joins program 1
This function can be configured at the system level or GPON port level. It can be used together with the multicast user bandwidth CAC. l GPON port ANCP bandwidth CAC [OLT] Generally, the IPTV service includes unicast stream and multicast stream, corresponding to VOD service and TV service respectively. By using ANCP, this bandwidth CAC function can be used on the RACS and VOD servers to implement bandwidth CAC (not only multicast bandwidth CAC) on all IPTV traffic streams. (For the ANCP principle, see "ANCP Feature.") This bandwidth CAC function can be configured at the system level. It cannot be used with the previous two bandwidth CAC functions.
Charging Mode
For multicast services, carries or ISPs usually adopt two charging modes: l Fixed charging. In this mode, programs are divided into different packages. The user needs to pay a fixed amount of fee for each package in a fixed period (such as by the year or by the month). This charging mode does not restrict the multicast user in the order count or the ordered volume of traffic. Pay per view (PPV): In this mode, the user is charged according to the order count of different programs.
In the first charging mode, since it is fixed charging, the charging does not relate to the behavior of the multicast user. Therefore, the first mode is supported by the device inherently and does not require additional functions from the device. In the second mode, the device can record the program order behavior of each multicast user and provides the behavior information in the form of a call detail record (CDR) to the accounting
13 Multicast
system for settling an account. The complete configuration of the CDR function consists of three steps: 1. Enabling the logging function. The function can be configured at the multicast user level, multicast program level (configurable for pre-configured programs, and defaulted to enable for dynamic programs), or system level. When a user finishes a complete watch behavior (from the program order starting to ending), or when the user fails to order a program because of failing to pass the multicast CAC, a log is generated.
NOTE
When the logs reach the maximum capacity, new logs will overwrite old ones. Therefore, to prevent heavy consumption of log resources in the case where the user quickly browses through channels, the device supports a configurable flag time for generating logs. If the multicast user watches a channel for a duration shorter than the flag time, the device does not generate a log. On the contrary, to timely log the users who stay online for a long time, the device supports the configuration of another time value (if the value is 0, the log will not be generated). When a user stays online for longer than the preset value, the device automatically generates a log.
2.
Configuring the file server. The operator needs to select a CDR transfer file. Available options are TFTP/FTP/SFTP. Also, the operator needs to set the IP addresses of the primary and secondary servers. Enabling the CDR functions (at system level). After the CDR function is enabled, the device automatically integrates the logs that need to be reported into a text file and transfers the file to the server when either of the following conditions is met: when the reporting interval expires, or when the number of logs reaches the reporting threshold. The format of the text file name is HWCDR-host name-YYYYMMDDHHMMSS.txt. Figure 13-20 Format of the text file
CDR item 1 ... CDR item n \r\n \r\n CDR file
3.
Table 13-5 Detailed format of a CDR item ID 0 1 2 Field Name TAG SN FrameSlotPortGemport FrameSlotPortFlow
Issue 01 (2011-10-30)
Specificati ons 3 bytes 0..5 bytes 5..13 bytes 5..14 bytes
Explanation Fixed as "Log." "Log" is the name of the module that generates syslog. A 16-bit variable. The maximum value is 65535 which occupies 5 bytes. F/S/P/GemPort for GPON users. F/S/P/FlowID for other types of user.
437
13 Multicast
ID 3 4 5 6 7 8 9
Field Name ProgramIP OperMode StartDate EndDate ProgramName ProgramSrcIP Reason
Specificati ons 0..15 bytes 0..1 bytes 0..18 bytes 0..18 bytes 0..16 bytes 0..15 bytes 1..2 bytes
Explanation For example, 239.1.1.1. 0-Watch; 1-Preview; 2-No Right; Otherinvalid. YYYY-MM-DD HH:MM:SS YYYY-MM-DD HH:MM:SS For example, cctv1. If the program does not exist, No-Name is displayed. For example, 192.168.1.1. If the IP address is invalid, * is displayed. Why syslog is generated: 11: User's online time is too long. 0: User leaves the multicast group.
Program Order Behavior Analysis

Compared with traditional TV services, in the case of IP multicast service, users' order behavior can be measured and analyzed at a finer grain, such as statistics measurement of hottest programs, analysis of user interest, and peak hours of program ordering. For such purposes, the device needs to precisely record the order behavior of each user in the form of logs and output the content of the logs through an open interface. According to different output modes, the device supports two log transfer modes: by CDR or by syslog (RFC 3164). The formats of the two modes are the same. For details, see "Charging Mode." The following table lists the pros and cons of the two modes. Table 13-6 Pros and cons of the two log transfer modes Pro CDR Reliable transfer. TFTP, FTP, or SFTP can be selected as the transfer protocol. Con Logs are reported to the file server only when specified reporting conditions are met (the reporting interval expires or the number of logs reaches the reporting threshold). Unreliable transfer. Syslog adopts the UDP protocol.
syslog
Timely report. Once a log is generated, it is uploaded to the syslog server.
Multicast Acceptance
After the construction of a site is completed, the site usually needs to be tested for acceptance. The major purposes of the acceptance test are to check the technique and quality (connectivity
13 Multicast
of hardware) of engineering installation and verify device configuration (correctness of software configuration and external interoperation parameters). On the BMS, the operator can perform an efficient and cost-effective acceptance test by performing the following steps: 1. 2. 3. Remotely configuring the data of access devices. Starting a simulation test. The simulation tests can be performed on multiple devices concurrently. Automatically obtaining the simulation test results without manual intervention. The flow of the multicast simulation test is as follows. Figure 13-21 Flow of the multicast simulation test
BMS AN Multicast router Multicast router Multicast source
Start simulation Send join message Multicast program Check multicast program traffic Report simulation result
Multicast program
Limited by the solution, the following items support the multicast simulation test during the acceptance test. Acceptanc e Item Multic ast service Multicast service User CAC control Simulation-Supporting Item Hardware connectivity of the network-side multicast network Access authentication Service connectivity of the network-side multicast network Correctness of the configuration of multicast service channels Non-SimulationSupporting Item User port Actual rate
At the same time, for the multicast simulation functions described above, the device provides open MIB interfaces for the secondary development by a third party.
13 Multicast
13.7.2 Protocol Interoperation

IGMPv3
IGMPv3 is defined in RFC 3376. Compared with IGMPv2 (RFC 2236), IGMPv3 has the following improvements: l Batch report. The destination IP address of report messages is always filled in as 224.0.0.22. Meanwhile, the IGMP payload can carry multiple group records, reducing the number of report messages between devices. As shown in the following figure, the IGMP message captured by a packet capture tool carries the information about two groups 232.1.1.1 and 239.255.1.5. With IGMPv2 messages, the destination IP address must be filled in as the corresponding group IP address. Hence, one IGMPv2 message cannot carry the information about multiple groups. Figure 13-22 Example of an IGMPv3 report message
Longer maximum response time for the query message. In IGMPv3, the maximum response time for the query message is extended from 25.5s (IGMPv2) to 3174.4s. Therefore, IGMPv3 is applicable to large-scale networks. Source filter. With the source filter function, the host can receive or not receive the multicast data carrying the IP address of a specified multicast source. This function enables the device to better implement SSM and support the multiple-ISP scenario. IGMPv2 supports only ASM. The following uses different types of messages to explain the implementation of source filter. Query messages General query The device sends this message to learn the reception status of an interface to "all" multicast groups. This is similar to the general query of IGMPv2. The device sends this message to learn the reception status of an interface to the multicast group with a specific address. This is similar to the group-specific query of IGMPv2.
440
Group-specific query
Issue 01 (2011-10-30)
13 Multicast
Group-and-sourcespecific query
The device sends this message to learn the reception status of an interface to the multicast group with a specific group address and source address. This is a new message of IGMPv3.
Report messages IS_IN(G, S) Reports the status. It indicates that the current mode of the group is the INCLUDE mode. This message is triggered when the device receives a query message. The source address list contains the source address S of the group. Changes the filter mode of the multicast group to the INCLUDE mode. The source address list contains a new source address S. TO_IN (G, {}) indicates leaving all sources of G and this message in this case is the same as the IGMPv2 leave message. Changes the source address list. This message is triggered when the source address changes. The source address contained in the record is the source address S that the system wishes to join. Changes the source address list. This message is triggered when the source address changes. The source address contained in the record is the source address S that the system does not wish to join. Reports the status. It indicates that the current mode of the group is the EXCLUDE mode. This message is triggered when the device receives a query message. The source address list contains the source address S that the group does not wish to join. IS_EX(G, {}) indicates that the device is interested in all sources of G and this message in this case is the same as the IGMPv2 join message. The device does not support the IS_EX message that contains an empty S. Changes the filter mode of the multicast group to the EXCLUDE mode. The source address list contains a new source address S that the device does not wish to join. TO_EX(G, {}) indicates joining all sources of G and this message in this case is the same as the IGMPv2 join message. The device supports the TO_EX message that contains an empty S.
TO_IN(G, S)
ALLOW(G, S)
BLOCK(G, S)
IS_EX(G, S)
TO_EX(G, S)
The following figure shows an example of the report message application.
Issue 01 (2011-10-30)
441
13 Multicast
Figure 13-23 Program ordering behavior converted into IGMPv3 messages

Access node Multicast router
Jion (S,G)
ALLOW(G,S) GQ IS_IN(G,S)
Leave (S,G)
BLOCK(G,S) GQ No Response
Jion (*,G)
TO_EX(G,{}) GQ IS_EX(G,{})
Leave (*,G)
TO_IN(G,{}) GQ No Response GQ: General query
IGMP Version Compatibility

The compatibility policies of the IGMP version on access devices distinguish between the network side and the user side. The IGMP version on the network side is configured based on MVLAN. As shown in the following table, according to the IGMP version on the multicast router, the IGMP version on the device should be set to the recommended version to avoid incompatibility. Incompatibility may cause packet loss. Multicast Router v1 v2 v3 MVLAN on Access Device v2/v3 v2 (recommended) v2 (recommended) Interoperation Result Incompatible Normal The device does not process IGMPv3 messages. Interoperation is normal only after the IGMP version on the multicast router is downgraded to v2. In normal application scenarios, the device is usually the active initiating party. The IGMP version on the multicast router can be seamlessly downgraded without packet loss.
Issue 01 (2011-10-30)
442
13 Multicast
Multicast Router v2
MVLAN on Access Device v3
Interoperation Result The multicast router does not process IGMPv3 messages. Interoperation is normal only after the IGMP version on the device is downgraded to v2. Before the downgrade, packet loss may occur.
v3
v3 (recommended)
Normal
The IGMP version on the user side cannot be directly configured and is determined by the earliest IGMP version of the MVLAN to which the multicast user belongs. As shown in the following table, according to the IGMP version on the terminal, the IGMP version on the device should be set to the recommended version to avoid incompatibility. Incompatibility may cause packet loss. Terminal v1 v2 v3 Multicast User on Access Device v2/v3 v2 (recommended) v2 Interoperation Result Incompatible Normal The device does not process IGMPv3 messages. Interoperation is normal only after the IGMP version on the terminal is downgraded to v2 (the terminal can be downgraded by enabling the function of periodically sending query messages to offline users). Before the downgrade, packet loss may occur. v2 v3 (recommended) The terminal does not process IGMPv3 messages. Interoperation is normal only after the IGMP version on the device is downgraded to v2. Even after downgraded to IGMPv2, the device can still identify the IGMPv3 messages sent from other terminals. This ensures greater compatibility of the device. In normal application scenarios, the terminal is usually the active initiating party. The IGMP version on the device can be seamlessly downgraded without packet loss. v3 v3 (recommended) Normal
SSM
According to the multicast source control level, multicast has three models: l Any-source multicast (ASM)
ASM is defined in RFC 1112. In this model, a recipient, by joining a group identified by the multicast address, can receive data sent to the group. A recipient can join or leave a group at any
13 Multicast
time, and the recipient location or quantity is not limited. In addition, any sender can serve as the multicast source to send data to the group. Therefore, this model is applicable to the multipoint-to-multipoint (MP2MP) multicast application. Figure 13-24 ASM network model
(G1,S1) R1 (G1,S2)
,S 1 )
1 (G
S1
(G1,S2) R2 (G1,S1) (G1,S2) ASM S2
R3
S3
R1 and R2 in the same group
Source-filtered multicast (SFM)
As an extension of ASM, SFM extends the source filtering function of the upper-layer protocol module. That is, in the SFM model, whether the multicast data of specified multicast source(s) is allowed to pass can be controlled. Viewed from recipients, SFM and ASM are different; but viewed from senders, they are the same. Therefore, SFM is the same as ASM in terms of network interoperability. Figure 13-25 SFM network model
,S 1 )
R1 (G1,S1)
1 (G
S1
(G1,S2) R2 (G1,S2) SFM S2
R3
S3
l
Issue 01 (2011-10-30)
Source-specific multicast (SSM)

13 Multicast
SSM is defined in RFC 4607. In this model, a recipient joins a channel by specifying the multicast source and group and receives data sent to the group from a specific multicast source. The recipient quantity is not limited. In addition, only the specific sender can serve as the multicast source to send data to the channel. Therefore, this model is applicable to the point-to-multipoint (P2MP) multicast application. Figure 13-26 SSM network model
1 ,S 1)
R1 (G1,S1)
(G
S1
(G1,S2) R2 (G1,S2) SSM S2
R3
S3
The following table lists the protocols that support ASM/SSM. Multicast Model Typical Protocol Combination of Devices in the Network STB ASM SSM IGMPv2 IGMPv3 AN IGMPv2 IGMPv3 Router PIM-SM PIM-SSM Inter-domain router MSDP/MBGP MBGP
Even if the user side does not support IGMPv3, carriers can implement SSM network on the network side. The device, with its SSM mapping function (can be supported automatically), can help implement the SSM networking on the network side even if the user-side device does not support IGMPv3. With the SSM mapping function, the device maps the received (*, G) message to an (S, G) message according to the unique multicast program triplet, as shown in the following figure.
NOTE
l A multicast user cannot belong to multiple MVLANs at the same time. l Dynamic programs do not support SSM mapping.
Issue 01 (2011-10-30)
445
13 Multicast
Figure 13-27 SSM mapping
Modem
AN
Multicast router
(*,G) SSM mapping
(S ,G)
Example:
(*,G1) (*,G2)
(VLAN1S1G1) (VLAN1S1G2) (VLAN1S1G3)
(S1 ,G1) (S1 ,G2)
The following table describes whether the devices support the SSM and ASM modes. User Side SSM ASM ASM SSM Network Side SSM ASM SSM ASM Supported or Not Supported Supported Supported Not supported
IGMP Snooping
IGMP snooping has two types: l IGMP transparent snooping It is a snooping function without proxy. The device selects the proxy, snooping, or snooping with proxy function based on the MVLAN. The device learns the IGMP join and leave messages of the multicast user to maintain the multicast group membership table, and then forwards the multicast data of the multicast upstream port to the corresponding multicast user according to the multicast group membership table. To maintain the aging of the multicast group membership table, the device also functions as a querier. The device processes the IGMP messages as follows: Query message
13 Multicast
After receiving the general query message and group-specific query message from the multicast upstream port, the device triggers the local querier to immediately send the recreated query message to the user side.
NOTE
l To ensure that the multicast user responds to the query in time, the maximum response time configured on the device must be shorter than that configured on the upper-layer multicast router. l The network-side IGMP version of the device is not affected by the multicast router.
Join/Leave message The device transparently transmits all the join/leave message received from the multicast user to the MVLAN.
NOTE
The IGMPv3 message may contain multiple group records that match different MVLANs. In this case, the device segments the message and transparent transmits the segmented messages to the corresponding MVLANs.
IGMP snooping with proxy In IGMP upstream transmission, IGMP snooping with proxy is the same as IGMP proxy; in IGMP downstream transmission, however, IGMP snooping with proxy does not suppress the query message as IGMP proxy does. Query message After receiving the query message from the multicast upstream port, the device sends the query message to the user and also responds to the multicast router's query according to its multicast group membership table.
NOTE
Like IGMP proxy, the network-side IGMP version of the device is affected by the multicast router.
Join/Leave message
The device sends only the first join message from the multicast users to the MVLAN. The device sends only the last leave message from the multicast users to the MVLAN.
Global Leave
As defined in TR101, the global leave message is an IGMP message with an all-zero group IP address, which indicates leaving all the groups. l Network side
When the network topology changes, the device sends the global leave message to the upperlayer multicast router. After receiving the message, the upper-layer multicast router immediately sends the general query message, with the maximum response time set to the maximum time of responding to the group-specific query message. The device, after receiving the query message, responds to the upper-layer multicast router with the join message of the interested group. In this way, the multicast service can recover more quickly. Here, the network topology change events include ring network switching, line up/down, and active/standby port switching in a protect group.
NOTE
l If the device is interconnected with a network device that does not support the global leave message, multicast services may be interrupted during the network topology change. Therefore, it is recommended that the global leave function be manually disabled on the device. l The device supports sending of the global leave message only in IGMPv2.
Issue 01 (2011-10-30)
447
13 Multicast
User side
When the STB is powered on immediately after a sudden power-off, because the STB cannot remember the previously-watched program, the bandwidth of the previously-watched program and the program resources are released only after the general query ages. If the STB supports the global leave function, the STB sends a global leave message after it is re-powered on. After receiving the message, the device sends a general query message, with the maximum response time set to the maximum time of responding to the group-specific query message. If the multicast user is a fast-leave or MAC-based fast-leave user, the device releases all program resources of this multicast user. If the user is a normal-leave user, the device sends a group-specific query message and releases the program resources after the group-specific query times out.
NOTE
Only the IGMPv2 global leave messages can be processed.
13.7.3 Network-side Interoperating Technologies

Multicast Cascading
On the access device, two types of multicast cascading are supported: l Ethernet cascading Using Ethernet cascading on the access device, the number of ports on the convergence device and the optical cable routing cost can be reduced. In addition, capacity expansion for more users in the residential community access area can be easily implemented. There are two common cascading network topologies, star (tree/chain) network and ring network, as shown in the following figure. Here, the star cascading network is used as an example. For details about the ring cascading network, see "Ring Network of Upstream Ports". Figure 13-28 Cascading network topologies
GE/10GE GE/10GE GE/10GE
GE/10GE GE/10GE GE/10GE
Star topology/Tree topology
Ring topology
Multicast cascading port configuration The device, through the Ethernet port of its GIU board or other cascading boards, can be physically connected to the lower-layer device. Multicast service is configured through the multicast cascading ports, and in this way the interoperation between the
13 Multicast
devices is managed. A multicast cascading port corresponds to a physical port (the channel for carrying services can be created through the port VLAN or service stream). The following figure shows the relationship between the multicast cascading port and the multicast upstream port. Figure 13-29 Multicast cascading port and upstream port
Multicast upstream port
Multicast subtending port Multicast upstream port Multicast upstream port
Multicast subtending port Multicast upstream port
Multicast subtending port
IGMP control message In the multicast cascading scenario, the upper-layer device and the lower-layer device run the IGMP protocol stack separately. For a device, the cascading port (its lower-layer device) can be regarded as the multicast user. Multicast users are controlled by the lower-layer device and therefore the device does not support the following service functions for multicast users: rights management, multicast preview, multicast CAC, charging, and multicast service acceptance. The device supports the fast leave and normal leave functions. On the cascading port, the IGMP protocol stack is based on different VLANs, as shown in the following figure. Figure 13-30 IGMP protocol stack on the cascading port
IGMP IGMP
H Service board H
Control board
Subtending board
Control board
Issue 01 (2011-10-30)
449
13 Multicast
NOTE
If an Ethernet port is not configured as the multicast cascading port, the Ethernet port discards the IGMP report message. The (SIP, GIP) field of the IGMP message and the VLAN of the IGMP message are used for program matching. The policy of processing unmatched messages can be configured based on the cascading port. Considering the IGMP processing performance of the source node, it is recommended that all cascading devices adopt IGMP proxy instead of IGMP snooping.
Multicast data forwarding Multicast data can be forwarded only in a VLAN. According to different cascading boards, there are two forwarding architectures. One-level forwarding architecture: The following figure uses the GIU board as an example. Figure 13-31 One-level forwarding architecture of multicast cascading
Service board
Service board
. . . Service board
Control board
. . . Subtending board
Control board
Index VLAN+ GMAC
Duplication Destination Ethernet port list
Two-level forwarding architecture: The following figure uses the ETHB/SPUA board as an example.
Issue 01 (2011-10-30)
450
13 Multicast
Figure 13-32 Two-level forwarding architecture of multicast cascading
Service board
Service board
. . . Service board
Control board
. . . Subtending board
Control board
Second-level forwarding table Index VLAN+ GMAC
First-level forwarding table Duplication Index Destination VLAN+ Service GMAC board list Duplication Destination Ethernet port list
xPON cascading [OLT] xPON cascading meets the requirements for multicast services in the FTTC/FTTB scenario. Multicast cascading port configuration The device can implement the physical connection between the OLT and the MxU by using the PON line. Similar to Ethernet cascading mode, in xPON cascading mode, the interconnection between devices is also managed through the multicast cascading port object. One xPON cascading port corresponds to a logical interface (GEM port or LLID). The actual bearer channel can be created by using the service port. The following figure shows the relationship between the xPON cascading port and upstream port.
Issue 01 (2011-10-30)
451
13 Multicast
Figure 13-33 xPON cascading port and upstream port

Multicast subtending port
Multicast subtending port Multicast upstream port
IGMP control packet In the xPON cascading scenario, the OLT and the MxU run the IGMP protocol stack separately. Like Ethernet cascading, xPON cascading supports normal leave and fast leave. On the multicast cascading port, the IGMP protocol stack is based on different VLANs, as shown in the following figure. Different from Ethernet cascading, in xPON cascading, the bearer channel is limited by the maximum number of service ports that can be created on each GEM port or LLID, because the bearer channel is based on the service port. To support an MVLAN that is beyond the supported specifications, you can configure multiple GEM ports or LLIDs.
Issue 01 (2011-10-30)
452
13 Multicast
Figure 13-34 IGMP protocol stack of the xPON multicast cascading port
MxU IGMP
Multicast data forwarding xPON cascading supports forwarding in the same VLAN and does not support crossVLAN forwarding. Figure 13-35 xPON multicast forwarding architecture
Service board
Service board
Service board
MxU
IGMP
Control board
OLT
H
IGMP
R
IGMP
Control board
H H
R R
H H
R R
PON board
Service board
Control board
MxU
Service board
OLT
. . .
. . Control board . PON board
Control board
First-level forwarding table Index Index VLAN+ GMAC Duplication Destination Port list Second-level forwarding table Index VLAN+ GMAC VLAN+ GMAC Duplication Destination PON port list Duplication Destination Service board list
Issue 01 (2011-10-30)
453
13 Multicast
NOTE
Service ports that adopt traffic classification by two-tagged VLANs do not support multicast cascading ports.
Ring Network of Upstream Ports

In the ring network, access devices on the physical link are connected to form a ring. Devices on the ring maintain the ring status by running the Layer 2 link protocol. The ring network of access devices has two advantages: l Low network construction costs: In the ring network, an access device does not need to connect to the convergence switch directly, but connects to its nearest access device. This greatly saves optical cable resources. The switch provides only a few ports for the access device. In the ring network, however, deploying a small number of switches can meet the access requirements. High reliability: The Layer 2 link protocol provides the uplink backup protection. With this function, when the uplink of a single access device is faulty, the device can switch to the backup uplink.
The multicast service supports the following two ring networks on the network side. l MSTP The mode of the multicast upstream port needs to be set to MSTP (system-level configuration). In this case, the multicast upstream port of the device does not need to be configured; instead, the root port determined dynamically by MSTP serves as the multicast upstream port. If the access device is the MSTP root bridge (this device must be the injection point of the multicast data; by using the MSTP priority configuration, ensure that this root bridge is not removed), the access device does not have the root port. Therefore, in the actual network, the multicast data injection port needs to be configured as the default multicast upstream port. In addition, the device ports on the ring need to be configured as the multicast cascading ports. The actual multicast downstream ports are determined by IGMP according to the multicast group membership table. The following figure shows the configuration of each role.
Issue 01 (2011-10-30)
454
13 Multicast
Figure 13-36 Multicast configuration in the MSTP ring network
Multicast router
AN 1
Default upstream port
Block
AN 2
Subtending port
AN 3
NOTE
l The root bridge must be the injection point of the multicast service. l When using the ETHA/ETHB/SPUA board for upstream transmission, the device does not support MSTP multicast.
In the case of a link or device failure, after MSTP selects a backup link, the multicast VLANbased IGMP protocol stack immediately sends the new root port (serving as the multicast upstream port) the join message targeting at the multicast group that the device is interested in. In this way, fast recovery of the multicast service can be ensured.
Issue 01 (2011-10-30)
455
13 Multicast
Figure 13-37 MSTP ring network fault
Multicast router
AN 1
Default upstream port Multicast upstream port after switching
AN 2
Faulty multicast upstream port
AN 3
RRPP The mode of the multicast upstream port needs to be set to RRPP (system-level configuration). In this case, the multicast upstream port of the device does not need to be configured either; instead, the ring upstream port determined dynamically by RRPP serves as the multicast upstream port. The RRPP master node, however, does not need to use the RRPP multicast upstream port mode, but needs to be configured with the correct multicast upstream port and multicast cascading port. In addition, the device ports on the ring need to be configured as the multicast cascading ports. The actual multicast downstream ports are determined by IGMP according to the multicast group membership table. The following figure shows the configuration of each role.
Issue 01 (2011-10-30)
456
13 Multicast
Figure 13-38 Multicast configuration of the RRPP ring network
Multicast router
AN 1
Block
AN 2 Subtending port
AN 3
NOTE
l The RRPP master node must be the injection point of the multicast service. l When using the ETHA/ETHB/SPUA board for upstream transmission, the device does not support RRPP multicast. l The device supports only RRPP single ring, and the single ring must be a primary ring.
In the case of a link or device failure, after RRPP selects a backup link, the multicast VLANbased IGMP protocol stack immediately sends the new ring upstream port (serving as the multicast upstream port) the join message targeting at the multicast group that the device is interested in. In this way, fast recovery of the multicast service can be ensured.
Dual-homing of Upstream Ports

Multicast routers 1 and 2 function as the active router and standby router respectively, as shown in the following figure. To ensure fast recovery of the multicast service after a switching, use the IGMP message broadcast function provided by the access node.
Issue 01 (2011-10-30)
457
13 Multicast
Figure 13-39 Upstream port broadcasting IGMP messages
Active R1
Standby R2
Report
Report
AN
First, set the two access node ports connected to routers 1 and 2 as the multicast upstream ports (the two ports must not be in the same aggregation group or protect group). After this setting, when the access node transmits IGMP messages to router 1, it transmits the same IGMP messages to router 2 at the same time. In this way, router 2 can maintain in real time the same multicast forwarding entry as that of router 1. Once a switching occurs, router 2 can directly obtain the multicast forwarding entry and can ensure fast recovery of multicast service in a shorter time. Note: If the router supports transfer of the multicast forwarding entry using a proprietary protocol, this can substitute for the upstream port dual-homing function. In this case, add the two access node ports to one aggregation group. Such a function is more commonly used in actual applications.
Prejoining a Program
The prejoin function is used to shorten the course of channel switching (reduce switching latency), improving users' experience in channel switching. Switching latency includes the processing time in each segment of a network, as shown in the following figure. With the prejoin function enabled, the network-side processing time (T1+T2) equals 0.
Issue 01 (2011-10-30)
458
13 Multicast
Figure 13-40 E2E multicast switching latency

TV STB Modem AN Multicast router Multicast router Multicast source
A T5 T4 T3 T2 T1
B T5 T4 T3
A: Processing latency of non-prejoin program = T1 + T2 + T3 + T4 + T5 B: Processing latency of prejoin program = T3 + T4 + T5
The prejoin function applies to the IGMP proxy scenario. It equals the situation where there are always online users for a program. l l The flow of prejoining a program is the same as the flow of normally joining a program. Once a multicast stream is successfully ordered, it is transmitted to the access node. Compared with the flow of leaving a normally joined program, the access node in the flow of leaving a prejoined program does not transmit the leave message to the multicast router even when the last multicast user leaves the program. Compared with the flow of querying a normally joined program, the access node in the flow of querying a prejoined program responds to the multicast router's query as required by the protocol regardless of whether the multicast group membership table of the program contains a multicast user.
Viewed from the router, there are always online users for a prejoined program. The prejoin function can be set for a program. In general, set the prejoin function for the program that is most commonly ordered by users. A dynamic program does not support the prejoin function.
CAUTION
All user leave packets are transparently transmitted after the transparent snooping function is enabled. This may cause the upper-layer router not to forward program streams. Therefore, the pre-join function cannot be used simultaneously with the transparent snooping function.
Issue 01 (2011-10-30)
459
13 Multicast
Source IP Address Matching for Certain Multicast Routers

Certain multicast routers can process only the IGMP messages in the same network segments as their Layer 3 interfaces. In IGMP proxy, however, the access device terminates the IGMP messages transmitted from multicast users and fills a new source IP address in IGMP messages. In this case, the source IP address of IGMP messages needs to be configured on the access node. Operators can configure the source IP address using any of the following solutions according to different needs. (If the solution with a higher priority is not configured, the configuration of the solution with a lower priority takes effect.) Validation Sequence Highest priority Second highest priority Solution Map to the primary IP address of the Layer 3 interface. Map to the host IP address of the program (invalid to a dynamic program because the host IP address of a dynamic program is unconfigurable). 0
Third highest priority
Other solutions: Certain multicast routers can set their Layer 3 interfaces to work in the hybrid mode and process IGMP messages regardless of whether their source IP addresses are in the same network segment as their Layer 3 interfaces.
13.7.4 User-side Interoperating Technologies

Fast Leave
l Normal leave As defined by IGMPv2, the router must send a group-specific query message after it receives the leave message from a host, and it considers that the host does not need the data of the group until the query times out. The following figure illustrates the flow of a normal leave (the same to IGMPv3).
Issue 01 (2011-10-30)
460
13 Multicast
Figure 13-41 Flow of a normal leave

PC STB Modem AN
Forward program 1 Normally leave program 1 Group-specific query (program 1) Join program 2 Forward program 2 Group-specific query (program 1) Query times out Stop program 1
Double bandwidth
Maximum bandwidth Program bandwidth
Two IGMP messages are transmitted in the case of a channel switching, one for leaving the original multicast group and one for joining the new multicast group. Therefore, traffic of two multicast groups exists on the subscriber line before the original multicast group is stopped. If the subscriber line does not reserve sufficient bandwidth for carrying the traffic of two multicast groups, traffic overflow (packet loss) will occur. For example, if video streams are carried, pixelation will occur. l Fast leave When the device receives the leave message from a multicast user, it immediately stops forwarding the messages of the user. The following figure illustrates the flow of a fast leave.
Issue 01 (2011-10-30)
461
13 Multicast
Figure 13-42 Flow of a fast leave

PC STB Modem AN
Forward program 1 Fast leave program 1 Stop program 1 Join program 2 Forward program 2
Maximum bandwidth Program bandwidth
Fast leave based on the MAC address When the device generates a multicast group membership table, it not only records the multicast user but also counts and records the MAC addresses of the multicast group members of the multicast user. A maximum of eight MAC addresses are supported for each multicast program. When the device receives a leave message, it first deletes the MAC addresses in the multicast group membership table, and it stops forwarding the messages of the group only when all the MAC addresses of the multicast user are deleted. The following figure illustrates the flow of a fast leave based on the MAC address.
Issue 01 (2011-10-30)
462
13 Multicast
Figure 13-43 Flow of a fast leave based on the MAC address

STB 1 STB 2 Index Program 1 Program 1 Program 1 Program 1 Destination Multicast user (MAC_STB1, MAC_STB2) Modem AN
STB 1 leave message 2 Program 1
Index Program 1
Destination Multicast user (MAC_STB2)
Program 1
STB 2 leave message 3 Index Program 1 Destination No forwarding entry
In summary, the three leave modes have their advantages and disadvantages. You can choose any of them according to actual needs and can set the leave mode for a multicast user. User-side Multi-STB Supported or Not Normal leave Yes The STB quantity is not limited. Fast leave Fast leave based on the MAC address No Yes One program supports a maximum of eight STBs at a time. Bandwidth Occupation Time Aged upon reception of groupspecific query Released immediately Released immediately
The following configurations are recommended and can be adopted by different users according to their home network topologies. HG Function No IGMP STB Quantity One Reserved Bandwidt h Insufficient Sufficient Several Insufficient Sufficient
Issue 01 (2011-10-30)
Normal Leave
Fast Leave
Fast Leave Based on the MAC Address (Less than eight)
(Less than eight)

463
13 Multicast
HG Function IGMP snooping
STB Quantity One
Reserved Bandwidt h Insufficient Sufficient
Normal Leave
Fast Leave
Fast Leave Based on the MAC Address (Less than eight)
Several
Insufficient Sufficient
(Less than eight) (Not limited) (Not limited) (Not limited) (Not limited)
IGMP proxy
One
Several
GPON Duplication Mode

If the service board of the device is a GPON service board, the device has two multicast forwarding mechanisms and you can configure the forwarding mechanism based on MVLAN. l Single-copy duplication This is the most common duplication mode of GPON multicast (it also refers to the mode mentioned in this document unless otherwise stated). This mode makes the best of the GPON downstream WDM transmission principle and sends multicast data to all ONTs using the non-encrypted GEM port bearer channel. Each ONT receives the multicast data according to the multicast filtering table. For the corresponding hardware forwarding entry, see "Multicast Forwarding Table." l Multi-copy duplication The primary difference between single-copy duplication and multi-copy duplication is that, in multi-copy duplication, multicast data is duplicated to corresponding service ports according to user requirements, encapsulated in the encrypted unicast GEM port channel, and then sent to the ONT. The following table shows the multicast forwarding table at the GPON board level. Index VLAN+GMAC Entry Multicast user list
Issue 01 (2011-10-30)
464
13 Multicast
Figure 13-44 Single-copy duplication and multi-copy duplication

ONT1 1 ONT2 1 ONT3 1
1
Multi-copy 1 1 1
OLT
1
1 1
Splitter
ONT1 1
1
OLT Single-copy 1
ONT2 1 ONT3 1 1
1
Splitter
The following table lists the differences between single-copy duplication and multi-copy duplication. Single-copy Duplication Duplicati on granularit y Bandwidt h Security Based on GPON port Multi-copy Duplication Based on multicast user
One GPON port has only one multicast stream. On the one hand, the security depends on the ONT filtering; on the other hand, the head end and STB encryption system are required. Supported Supported
One multicast user has only one multicast stream, but one GPON port may have multiple multicast streams. This mode uses the GPON line AES128 encryption system and the real-time key conversion function, which provides better security than the common encryption system of the head end. Not supported Stacking VLAN multicast users cannot be configured with stacking VLANs.
CAC of PON port Singletagged multicast stream
Issue 01 (2011-10-30)
465
13 Multicast
Single-copy Duplication Dualtagged multicast stream Supported
Multi-copy Duplication If the S-VLAN of a multicast user is a stacking VLAN, the multicast stream VLAN (MVLAN) must be the same as the S-VLAN. That is, cross-MVLAN duplication is not supported.
GPON ONT Multicast

The GPON end-to-end multicast service requires the cooperation of the ONT. The following points must be noted: l VLAN translation If the carrier plans the home gateway at the user's house, generally, the VLAN of the IPTV service (also called C-VLAN) needs to be planned. Because the OLT does not directly support translation of the MVLAN, the operator can configure VLAN translation on the ONT to meet the planning requirement (the OLT provides the corresponding CLI and the configuration can be issued to the ONT through OMCI). The MVLAN can be translated in three ways: transparently transmitted, translated to untagged, and translated to a specified VLAN. l Controllable multicast In single-copy duplication, GPON downstream multicast programs are broadcast. Assume the following condition: After an authorized multicast user orders a program, all users under the GPON port can receive this program. Therefore, to implement complete rights control on the access device, the OLT must configure the ONT to work in the "dynamic controllable" mode. In this way, the multicast filtering table (white list) on the ONT is issued by the OLT after multicast control checking. If a downstream multicast program is not in the multicast filtering table, the ONT cannot receive this multicast program. If the ONT is configured to work in the "IGMP snooping" mode, the multicast filtering table on the ONT is completely maintained by the ONT. In this case, multicast program rights management is generally implemented by the encryption system of the IPTV platform.
13.7.5 Interoperating Technologies Between Specific Ends

Double-Tag Multicast [OLT]
Double-tag multicast specially refers to the number of VLAN tags of packets carried by the network-side multicast of the access device. In actual multicast networks, generally only one VLAN tag is used for multicast. The reasons for using double-tag multicast are as follows: l The unicast application is limited by 4K VLANs and more and more applications adopt the double-tag planning. In addition, because the convergence switches of some vendors interconnected with the access device do not support transmission of single-tag packets and double-tag packets on the same physical link, the multicast has to adopt the double-tag mode. To use the VLAN planning like that of unicast in a unified manner. For example, outer VLAN tags indicate different ISPs and inner VLAN tags indicate different services.
The device can be configured whether to use the double-tag multicast function.
13 Multicast
IGMP control message Double-tag multicast and single-tag multicast have the same processing flow for IGMP control messages (see 1.6.4 "Multicast Forwarding Flow"). Difference between them: On the network side, the transmitted and received IGMP messages in single-tag multicast have one tag whereas the transmitted and received IGMP messages in double-tag multicast have two tags The outer VLAN tag in double-tag multicast is the MVLAN to which the program belongs and the inner VLAN tag can be configured based on MVLAN (adopting the "easy in strict out" principle, the device does not check the inner tag and configuration consistency of received IGMP messages).
Multicast data hardware forwarding The data forwarding flow of double-tag multicast streams varies according to the GPON duplication mode. If the multicast duplication mode is multicast (single-copy duplication), multicast streams are forwarded on the control board and service board according to the multicast forwarding entry. The VLAN carried by the multicast streams forwarded to the ONT is the CVLAN. Because of the multicast duplication feature, in this scenario, the inner VLAN is often directly defined as the MVLAN (In addition, the device currently supports only this scenario).
NOTE
This scenario is applicable only when the TPID is 0x8100.
Figure 13-45 Double-tag multicast hardware forwarding (single-copy duplication)

OLT
Service board
Control board
MVLAN
Inner VLAN
ONT Unicast data channel
Service board
MVLAN
Inner VLAN
Multicast data channel
Inner VLAN
Forward data according to the multicast forwarding table
If the multicast duplication mode is unicast (multi-copy duplication), multicast streams are forwarded on the control board according to the multicast forwarding entry and on the service board according to the configured service port. The VLAN carried by the multicast streams forwarded to the ONT is the CVLAN. In this scenario, the inner VLAN is often defined as the CVLAN.
Issue 01 (2011-10-30)
467
13 Multicast
Figure 13-46 Double-tag multicast hardware forwarding (multi-copy duplication)

Service board
Control board
MVLAN
Inner VLAN
ONT Unicast data channel
Service board
CVLAN Multicast data channel
MVLAN
Inner VLAN
Forward data according to the configured data after VLAN translation
Transparent Transmission of Multicast Data

l Transparent transmission of multicast data for private-line users Transparent transmission of IGMP messages In the upstream direction, the service board determines whether to transparently transmit the received IGMP messages according to the VLAN-level IGMP transparent transmission policy and service-port-level transparent transmission policy. If transparent transmission is allowed, IGMP messages are added with the SVLAN tag on the service board and then are transmitted to the control board. After arriving at the control board, IGMP messages are broadcast by the control board within the SVLAN. If transparent transmission is not allowed, IGMP messages are dropped. In the downstream direction, the IGMP messages transmitted from the network side are broadcast by the control board within the SVLAN and after they arrive at the service board, the service board determines whether to transparently transmit them according to the VLAN-level IGMP transparent transmission policy and service-port-level transparent transmission policy. If transparent transmission is allowed, the service board translates the SVLAN tag to the CLAN tag according to the configuration of the traffic stream and then transmits the messages to users. If transparent transmission is not allowed, IGMP messages are dropped. Transparent transmission of unknown multicast data In the upstream direction, the service board determines whether to transparently transmit the received unknown multicast data according to the VLAN-level IGMP transparent transmission policy and service-port-level transparent transmission policy. If transparent transmission is allowed, IGMP messages are added with the SVLAN tag on the service board and then are transmitted to the control board. After arriving at the control board, IGMP messages are broadcast by the control board within the SVLAN. If transparent transmission is not allowed, IGMP messages are dropped. In the downstream direction, the unknown multicast data transmitted from the network side is broadcast by the control board within the SVLAN and after the data arrives at the service board, the service board determines whether to transparently transmit the
13 Multicast
data according to the VLAN-level IGMP transparent transmission policy and serviceport-level transparent transmission policy. If transparent transmission is allowed, the service board translates the SVLAN tag to the CLAN tag according to the configuration of the traffic stream and then transmits the data to users. If transparent transmission is not allowed, unknown multicast data is dropped.
NOTE
To prevent the multicast data of the multicast user provisioned with multicast service from being transmitted to the upstream unauthorized multicast sources, make sure that the policy of transmitting unknown multicast data is set to drop. The transparent transmission policies of unknown multicast traffic have the switches of two levels on a service board: the VLAN level and the service port level. When the two switches are both set to transparent transmission, the policy is transparent transmission. When either of the two switches is set to drop, the policy is drop. (Only transparent transmission is supported for connection-oriented traffic and the policy is not configurable in this case.)
Co-existence of IPTV service and transparent transmission of multicast data Multi-service-port solution IPTV service and multicast transparent transmission service are carried on two service ports, and the SVLAN of the service port that carries multicast transparent transmission service must not be the MVLAN. The service port that carries IPTV service processes the received IGMP messages following the flow of processing IPTV service, and forwards the multicast data according to the multicast forwarding entry. The service port that carries multicast transparent transmission service transparently transmits or drops the received IGMP messages according to the IGMP transparent transmission policy of the traffic stream, and transmits or drops the received unknown multicast data according to the unknown multicast transparent transmission policy of the traffic stream. Single-service-port solution IPTV service and multicast transparent transmission service are carried on one service port, whose SVLAN must not be the MVLAN. When the Access Node receives upstream IGMP messages, it matches the multicast group address in IGMP messages to the programs in the MVLAN. If the group address successfully matches a program, the Access Node processes the messages as IPTV service. If the group address fails to match any program, the Access Node determines whether to transparently transmit the messages according to the IGMP transparent transmission policy of the SVLAN and service port. The Access Node transparently transmits the messages only when the IGMP transparent transmission policy is enabled for both the SVLAN and service port. If the Access Node receives downstream IGMP messages that carry the MVLAN tag, the Access Node processes the IGMP messages as IPTV service. If the messages carry the SVLAN tag, the Access Node forwards them according to the IGMP transparent transmission policy of the SVLAN and service port. The Access Node transparently transmits the messages only when the IGMP transparent transmission policy is enabled for both the SVLAN and service port. If the Access Node receives the multicast data of IPTV service, the Access Node forwards the multicast data according to the multicast forwarding entry. If the multicast data is unknown, the Access Node forwards the data according to the unknown multicast transparent transmission policy of the VLAN and service port. The Access Node transparently transmits the data only when the unknown multicast transparent transmission policy is enabled for both the SVLAN and service port.
Issue 01 (2011-10-30)
469
13 Multicast
13.8 Multicast Fault Diagnosis

This topic describes only the principles of fault diagnosis for multicast services. For details about troubleshooting (from fault symptom to troubleshooting procedure), see the Troubleshooting.
User Log
The device log records the program order history of users (for only the programs complying with the defined time marking). The log includes the port to which a user is connected, IP address of the program group, multicast VLAN (MVLAN), time when a user starts watching a program, time when a user stops watching a program, and log mode (for example, watch, preview, idle, or preview threshold crossing). A log is generated in any of the following scenarios: l l Normal channel switching. In such switching, the interval between receiving a leave packet to receiving a join packet is longer than the defined time. Ordering failure. The common causes of an ordering failure are as follows: The user does not have the right to watch the program. The maximum number of programs the user can watch concurrently is exceeded. The bandwidth CAC fails. l l l l Daily preview threshold crossing. Quiet leaving. In quiet leaving, the user does not respond to the general query of the device. Long-time program watching. "Long-time watching" means that the watch time reaches the maximum duration configured in the system. Operations that cause a user to go offline, for example, deleting or blocking a user.
Logs can be queried according to different query criteria, including by user, by program, by a specified period with regard to a user, and by a specified period with regard to a program. If users need to learn only the log quantity, the log statistics function is recommended. This frees users from reading multiple pages of numerous logs that are generated after the device has been running for a long time. Users can also use the log clearing function to delete unwanted old logs. Logs of all users or of a specified user be deleted.
Multicast Ping
By using the command line interface (CLI), multicast ping is a function with which a general query packet or group-specific query packet is sent to a specified multicast user or multicast cascading port. The version of such a packet is determined by the current version supported by the packet destination. After a report packet from the specified multicast user or multicast cascading port is received, the group IP address and source IP address of the report packet are displayed on the CLI. If no report packet is received within 10s, a timeout message is displayed on the CLI. Note that only xDSL/OPFA boards support this function currently.
IGMP Packet Statistics

A multicast program is ordered by using the Internet Group Management Protocol (IGMP). Therefore, correctly sending, receiving, and processing IGMP packets is the prerequisite for
13 Multicast
successful program ordering. To facilitate fault locating in IGMP packet transmission/reception, the device supports three levels of IGMP packet statistics: global level, MVLAN level, and traffic stream level. On the network side, the number of received IGMP query packets and number of sent IGMPv2/ v3 join/leave packets can be queried based on MVLAN. According to the packet count, whether the upper-layer router is faulty can be determined. On the user side, the number of received IGMPv2/v3 join/leave packets and number of sent IGMP query packets can be queried based on traffic stream. According to the packet count, whether a device in the home network is faulty can be determined.
Multicast Traffic Statistics Query

By querying multicast traffic statistics, users can determine whether multicast data reaches the ingress/egress of the device at the forwarding layer or whether packet loss occurs due to a low rate. The device supports four query modes on the network side: l l l l A1: querying the number of sent/received multicast packets on an Ethernet port A2: querying the ingress traffic (unit: kbit/s) of a specified multicast program (a preconfigured or dynamic program) or of a specified multicast upstream port A3: querying the number of required multicast packets (filtered by ACL) in the inbound direction of an Ethernet port A4: querying the number of sent/received multicast frames on a PON port of an MDU that uses GPON upstream transmission B1: querying the number of sent/received multicast frames and number of sent bytes on a PON port B2: querying the number of sent/received multicast frames of a specified ONT connected to an EPON board (The GPON board supports the command for this query mode but no multicast information is displayed.) B3: querying the number of sent/received multicast frames on an Ethernet port of a specified ONT C1: For the multicast traffic copied to service ports (for xDSL boards, P2P boards, and GPON boards that use multi-copy duplication), the traffic statistics (sent/received bytes) of a specified service port can be queried to obtain the multicast traffic statistics. This method is not suitable when a service port carries other services besides the multicast service. C2: For xDSL boards, P2P boards, or GPON/EPON boards that use single-copy duplication, the number of sent packets of queues on a specified port can be queried to obtain the multicast traffic statistics. This method is not suitable when queues on a port carry other services besides the multicast service.
On the user side, the device supports three query modes for the GPON board: l l
The following two methods can also be used to query the user-side multicast traffic statistics: l
Figure 13-47 shows the points where multicast traffic can be queried.
Issue 01 (2011-10-30)
471
13 Multicast
Figure 13-47 Points of multicast traffic query

Support C1/C2 Support A4 DSL board Support A1/A2/A3
MDU Support B2 Support B1 Support B3
Control board
PON board Multicast router
ONT Support C1 Support C2
OLT
13.9 Multicast QoS

This topic describes the quality of service (QoS) features dedicated to the multicast service. For more information about QoS (including traffic classification, traffic policing, ACL policy, and congestion avoidance and management), see the QoS-related feature description.
Priority Processing of IGMP Packets

The device supports processing of only the 802.1p priority (CoS) of IGMP packets. Table 13-7 Priority processing in IGMP proxy/snooping Upstream Multicast user/xPON cascading (except for the EPBA board) Based on MVLAN. Downstream Traffic classification methods: l VLAN: by the 802.1p priority specified in the traffic profile. l VLAN+encapsulation type: by the 802.1p priority specified in the traffic profile. l VLAN+802.1p priority: by the 802.1p priority specified by traffic classification. Ethernet/ EPBA cascading Based on MVLAN. Based on MVLAN.
Priority Processing of Multicast Traffic Streams

The device supports processing of only the 802.1p priority (CoS) of the multicast traffic streams.
13 Multicast
Table 13-8 Downstream multicast priority processing Pre-configured Program Multicast user/xPON cascading (except for the EPBA board) Ethernet/ EPBA cascading Traffic classification methods: l VLAN: by the 802.1p priority specified in the traffic profile. l VLAN+encapsulation type: by the 802.1p priority specified in the traffic profile. l VLAN+802.1p priority: by the 802.1p priority specified by traffic classification. Based on program. The priority is not configurable. That is, the priority carried remains unchanged. Dynamic Program
13.10 Network Application

Figure 13-48 GPON FTTx multicast network application
IGMP snooping
FTTH TV ONT
IGMP proxy
Optical splitter FTTB/FTTC TV MxU
OLT
Multicast router
Multicast router
Multicast source
IGMP prxoy multicast VLAN mode
Issue 01 (2011-10-30)
473
14 Network Protection Features
14
About This Chapter
Network Protection Features
This topic describes network protection features implemented by the system. 14.1 Ethernet Link Aggregation Ethernet link aggregation refers to aggregation of multiple Ethernet ports to form one port to provide higher bandwidth and link security. 14.2 Protection Group of Uplink Ports After a protection group of upstream ports are configured, when the primary upstream port fails, the data can be transmitted in the upstream direction through the secondary upstream port. This topic provides introduction to this feature and describes the principle and reference documents of this feature. 14.3 Smart Link and Monitor Link The smart link is a solution that is applied in the dual-upstream-transmission network and provides reliable and high-efficiency backup and quick switching for the dual uplinks. The monitor link solution, as a supplementary to the smart link solution, is used to monitor the uplinks. 14.4 MSTP The Multiple Spanning Tree Protocol (MSTP) is compatible with STP and RSTP. 14.5 RRPP Rapid Ring Protection Protocol (RRPP) is a link-layer protocol specially used for protecting Ethernet ring networks. 14.6 BFD 14.7 STM-1 Port Protection Switching This topic describes the feature of STM-1 port protection switching. 14.8 Type C Protection of GPON Lines This topic describes the type C protection of GPON lines. 14.9 GPON Port 1+1 Backup This topic describes the introduction, principle, and reference documents of the feature GPON port 1+1 backup.
14.1 Ethernet Link Aggregation

Ethernet link aggregation refers to aggregation of multiple Ethernet ports to form one port to provide higher bandwidth and link security.
14.1.1 Introduction
Definition
The link aggregation group (LAG) aggregates multiple physical links to form a logical link with a greater rate to transmit data. The domain where the link aggregation works is among devices and is not relevant to the architecture of the entire network. In an Ethernet, a link maps a port. Therefore, link aggregation is also called port aggregation. The Link Aggregation Control Protocol (LACP) is the control protocol that is specified in the IEEE 802.3ad standard for implementing link aggregation. Through LACP, the Ethernet ports of different devices can be automatically aggregated without interventions from the user, and the link layer failure of the ports can be detected, so as to implement control over link aggregation control.
Purpose
A link aggregation group provides the following functions: l Increasing the link bandwidth A link aggregation group provides an economic way of improving the link capacity for users. By binding multiple physical links, users can obtain a data link with higher bandwidth without upgrading the current device. The capacity of the data link is equal to the sum of capacities of all physical links. The aggregation module allocates different traffic streams to its different member physical links according to the load balancing algorithm, so as to achieve the link-level load balancing function. l Enhancing the link security In a link aggregation group, the member physical links are backed up with each other dynamically. When a link is disconnected, another link can take the place of the faulty link.
Type of Link Aggregation

Link aggregation can be classified into manual link aggregation, dynamic link aggregation, and static link aggregation. Currently, the MA5600T/MA5603T supports manual link aggregation and static link aggregation but does not support dynamic link aggregation. l Manual link aggregation Manual link aggregation is an aggregation group that is manually created by a user and LACP is not run for adding a port to the aggregation group or deleting a port from the aggregation group. A port has two states: up and down. Whether ports can be aggregated depends on their physical states (up and down). LACP is not used for manual link aggregation and thus devices at the two ends of a link are not exchanged for aggregation negotiation. Therefore, aggregation control is not precise or effective. For example, if a user incorrectly connects physical links to different devices or to ports (on a same device) that cannot be aggregated, the system cannot detect such
incorrectness. In addition, manual link aggregation can work only in the load balancing mode and its applications are limited to a certain extent. l Dynamic link aggregation Dynamic link aggregation is set up without interventions from the user, which adds the plug-and-play function to a device. In actual applications, however, dynamic link aggregation is over flexible, which is inconvenient for users. For example, an aggregation group is set up dynamically and thus the aggregation group ID may be changed when the device is restarted. This brings difficulty in managing the device. l Static link aggregation Static link aggregation is an aggregation group that is manually created by a user and LACP is run for adding a port to the aggregation group or deleting a port from the aggregation group. Ports in an aggregation group have two states: selected and standby. Through LACP, devices exchange the aggregation information to make the aggregation information to be the same. The port in the selected state is a working port, which carries traffic. The port in the standby state is a standby port, which does not carry traffic. Therefore, in a static link aggregation group, not all the member ports work at the same time. In addition, the port state (selected and standby) varies with change of running of the device or the ambient environment. This makes the static link aggregation group feasible to work in the load balancing mode or the active/standby mode. Compared with manual link aggregation, static link aggregation controls aggregation more accurately and effectively.
LAG Working Mode

An LAG supports the following two working modes: l Load balancing mode In the load balancing mode, all member links in the aggregation group carry traffic at the same time, that is, these links balance load. In this mode, links provide a higher bandwidth. When LAG members change or certain links fail, the system automatically reallocates traffic. l Active/standby mode In the active/standby mode, only one link in the aggregation group is in the selected state and this link carries traffic, and the other links in the aggregation group are in the standby state. This is a hot standby mechanism. When a selected link in an aggregation group fails, the system will select a link in the standby state to serve as the selected link, so as to protect against link failure.
The Ethernet link aggregation of the MA5600T/MA5603T supports the following specifications: l Supports Ethernet intra-board aggregation and inter-board aggregation. Intra-board aggregation: Two or more ports are bound and are used as one port. The ports in an aggregation group balance load and protect the link of each other. Inter-board aggregation: Two or more ports on two neighboring service boards or on the control board and the upstream board are bound and used as one logical port. This logical port is also called the aggregation group or link aggregation group (LAG).
l l l l l l l
The MA5600T/MA5603T supports up to 512 LAGs and up to eight physical ports in an LAG. The MA5600T/MA5603T supports up to 256 LACP ports. Supports manual link aggregation and static link aggregation but does not support dynamic link aggregation. Supports link aggregation in the load balancing mode or in the active/standby mode. Supports link aggregation of M primary links and N secondary links in an aggregation group. Load balancing supports packet forwarding based on source MAC address or source MAC address+destination MAC address. Supports the following inter-board aggregation: Supports inter-ETHB-board aggregation. Supports inter-SPUA-board aggregation, and aggregation and deaggregation of ports on the SPUA boards carrying services (only one board can be configured with services). Supports inter-OPGD-board aggregation, and aggregation and deaggregation of ports on the OPGD boards carrying services (only one board can be configured with services). Supports inter-SCUN-board aggregation. Supports inter-board aggregation between the SCUN and GIU boards. Supports inter-GIU-board aggregation.
The switching duration between ports in the inter-board aggregation group is less than 200 ms.

The following lists the reference standards and protocols of this feature: l l l IEEE 802.3ad, link aggregation (trunking) IEEE 802.3u, 100BASE-FX IEEE 802.3z, 1000BASE-X
14.1.4 Availability
Relevant NE
To enable the link aggregation feature to take effect, the device that is connected to the MA5600T/MA5603T must support link aggregation. The device that is connected to the MA5600T/MA5603T refers to the upstream device, namely the network-side device, such as an Layer 2 switch, Layer 3 switch, or router.
License Support
The Ethernet link aggregation feature is a basic feature of the MA5600T/MA5603T. Therefore, the corresponding service is provided without a license.
Issue 01 (2011-10-30)
477
Version Support
Table 14-1 Version Support Product MA5600T/MA5603T Version V800R007 and later versions
Feature Dependency
l l Only the ports of the same type (the ports of the same type, working mode, and rate) can be aggregated into a link aggregation group. Boards (ETHB, SPUA, and OPGD) supporting inter-board aggregation must be in neighboring slots. In addition, before configuring inter-board aggregation, make sure that the two service boards must be bound. Supports creation of protect groups between the aggregation group of the active control board and that of the standby control board. Note that other boards except control boards do not support creation of protect groups between the aggregation groups. Supports creation of protect groups within a same aggregation group. The aggregation group in protect groups, however, cannot contain a port that is not added to a protect group.
Hardware Support
The SCUN, SCUB, SPUA, ETHB, and OPGD, and GIU boards support the intra-board Ethernet link aggregation feature. The ETHB, SPUA, OPGD, GIU boards, and the SCUN and GIU boards support inter-board link aggregation. Table 14-2 shows inter-board link aggregation of MA5600T. Table 14-2 Inter-board link aggregation of MA5600T Board Name ETHB Backplane MABC.VER.A/ MABH.VER.B Supports inter-board aggregation only when cables led out from its front panel. Not support inter-board aggregation Backplane MABC.VER.B/ MABH.VER.C Supports inter-board aggregation directly through the backplane. That is, connection is not required. Supports inter-board aggregation directly through the backplane. That is, connection is not required. Supports inter-board aggregation directly through the backplane. That is, connection is not required. Slots for Inter-Board Aggregation 1-2, 3-4, 5-6,...
SPUA
1-2, 3-4, 5-6,...
OPGD
Not support inter-board aggregation
1-2, 3-4, 5-6,...
Issue 01 (2011-10-30)
478
Table 14-3 shows inter-board link aggregation of MA5603T. Table 14-3 Inter-board link aggregation of MA5603T Board Name ETHB Backplane MABO Supports inter-board aggregation directly through the backplane. That is, connection is not required. Supports inter-board aggregation directly through the backplane. That is, connection is not required. Supports inter-board aggregation directly through the backplane. That is, connection is not required. Slots for Inter-Board Aggregation 0-1, 2-3, 4-5,...
SPUA
0-1, 2-3, 4-5,...
OPGD
0-1, 2-3, 4-5,...
14.1.5 Feature Enhancements

Table 14-4 shows the enhanced Ethernet link aggregation feature. Table 14-4 Enhanced Ethernet link aggregation feature Version V800R008 Enhancement l Supports inter-OPGD-board aggregation. l Supports link aggregation between the SCUN board and the GIU board.
14.1.6 Principle
14.1.6.1 Introduction to LACP
The Link Aggregation Control Protocol (LACP) is based on the IEEE 802.3ad standard, which provides the following functions: l Provides a standard negotiation mode for devices exchanging data. The system generates an aggregation link automatically based on its configurations and enables the aggregation link to receive and transmit data. After being generated, the aggregation link maintains the link state. In addition, when aggregation conditions change, the aggregation link is adjusted or dismissed automatically.
LACP aggregates links between device A and device B in the following steps:
1.
Device A exchanges LACP packets with device B through port 1, port 2, port 3, and port 4. The LACP packet contains the system priority, MAC address, port priority, port ID, and operation key. The operation key reflects the aggregation capability of a port, which is determined by various factors such as physical features (including rate and duplex), configuration restrictions set by the network administrator, and features and limitations of ports. After receiving LACP packets sent from device A, device B compares the information about LACP packets with the information saved by other ports and then selects the ports that can be aggregated. After receiving LACP packets sent from device B, device A compares the information about LACP packets with the information saved by other ports and then selects the ports that can be aggregated. Device A and device B determine the same ports that can be aggregated into an aggregation group and thus a link aggregation group is generated, as shown in Figure 14-1.
2.
3.
4.
Figure 14-1 LACP application
Device A
LAG
Device B
Port1 Port2 Port3 Port4
Port1 Port2 Port3 Port4
Features of LACP are as follows: l l The system implements auto-negotiation by exchanging protocol packets. These packets contain the system configurations and the current status. The protocol packets are transmitted in the following two modes: Event trigger Events caused by status change or configuration change trigger generation and transmission of the new protocol packets. Periodic transmission When an aggregation link works normally, the system periodically transmits its current status to maintain aggregation. l The protocol packets are not numbered. Therefore, device A and device B do not use the check mode or retransmission of the lost protocol packets to prevent information from loss; instead, they use the timer and periodic transmission to prevent information from loss. Up to five protocol packets can be transmitted every second.
After an aggregation link is generated, member ports in the aggregated link have two states: selected and standby. The selected and standby states are states of the aggregated ports
maintained at the LACP protocol layer, not the physical states of the ports. If the physical states of the ports change, the states of the ports at the LACP protocol layer also change. For example, if an aggregated port is faulty, the state of the port at the LACP protocol layer will change to the standby state. Not only the state change of the physical port, but also the exchange of (LACP data units) LACPDUs can result in a change in the state of the port at the LACP protocol layer. For example, when receiving an LACPDU from the peer end, the status of a port may change. In this case, LACP improves security of link aggregation. The following lists aggregation link states that can be checked. l l l l Change of a physical port status Board fault Failure to forward packets on a port Change of the aggregated port on the peer end
LACP also supports such mechanisms as system priority, port priority, and short or long timeout. l System priority In LACP, the system priority is used for controlling the master/slave relation of the interconnected devices. The slave device must select the selected port according to the selection result of the master device. Otherwise, the two devices cannot be interconnected with each other. l Port priority The port priority is used for selecting the master port and the slave port. l Timeout To guarantee the LACP check sensitivity, IEEE 802.3ad defines two timeout periods: short timeout and long timeout. The two timeout values can be adjusted. A device cannot use the short timeout to exchange information with the peer device unless the peer device notifies the device of using the short timeout. Otherwise, the device always uses the long timeout to exchange and transmit information. The MA5600T/MA5603T supports the following timeout values: Short timeout: 1-10s Long timeout: 20-40s
14.1.6.2 Principle of Implementing Link Aggregation

The MA5600T/MA5603T supports manual link aggregation and static link aggregation. A manual link aggregation group supports only the load balancing mode, while a static link aggregation group supports both the load balancing mode and the active/standby mode.
Load Balancing Mode

Here, take aggregation of two ports on the control board as an example. When the load balancing mode is adopted, member links in the aggregation group are in the selected state and each link carries traffic; this indicates that the load of these links is balanced, as shown in Figure 14-2.
Links L1 and L2 are members of LAG1. The MA5600T/MA5603T and the switch at the peer end need to aggregate the corresponding two ports to an aggregation group respectively. Links L1 and L2 are in the selected states and both carry traffic. The load balancing policy can be configured based on the source MAC address or based on the source MAC address and the destination MAC address. If a port of the MA5600T/MA5603T is faulty or the corresponding link is faulty, the control board of the MA5600T/MA5603T will not transmit traffic to the faulty port.
Figure 14-2 Link aggregation in the load balancing mode
LAG Selected L1 S C U S C U Selected L2 Switch
Signal flow direction
Active/Standby Mode
Here, take aggregation of two ports on the control board as an example. When the active/standby mode is adopted, only one link in the aggregation group is in the selected state and this link carries traffic, and the other links in the aggregation group are in the standby state. This constructs a hot standby mechanism. When a selected link in an aggregation group fails, the system will select a link in the standby state to serve as the selected link, so as to protect against link failure, as shown in Figure 14-3. l l l l Links L1 and L2 are members of LAG1. Link L1 is in the selected state and carries traffic. Link L2 is in the standby state and does not carry traffic, but just constructs a hot standby mechanism with link L1 When link L1 fails, the system uses link L2 as the selected link.
Figure 14-3 Link aggregation in the active/standby mode
LAG Selected L1 S C U S C U Standby L2 Switch
Signal flow direction

14.1.6.3 Principle of Implementing Inter-Board Aggregation

The external characteristics of inter-board aggregation, such as the number of aggregated ports and load balancing policy, are the same as those of the intra-board aggregation. Before using the inter-board aggregation feature, make sure that the two boards support interboard aggregation and are interconnected through the backplane or front panel. Here, take principles of implementing inter-board aggregation of GIU as an example, as shown in Figure 14-4. Figure 14-4 Principle of implementing inter-board aggregation
GIU Service Board SCU
GIU
If the two GIU boards work in the normal state, the traffic streams from the service board are shared according to the MAC address carried in the packets. That is, the traffic streams are allocated to all the aggregated ports on the boards. If the port on one GIU board fails (Link down), the traffic stream carried on the failed port will be switched to the normal port on the other board. If one GIU board fails, the traffic stream carried on the faulty board will be switched to the normal board.
l l

Upstream Transmission of Intra-Board Link Aggregation
The SCU, ETHB, SPUA, and GIU boards can be used for common upstream transmission. If one board provides multiple GE ports for upstream transmission, the inter-board link aggregation can be used to provide higher bandwidth, so as to improve reliability, as shown in Figure 14-5. This type of network topology increases bandwidths (through the load balancing mode) and protects links. A board in case of a failure, however, cannot be protected.
Issue 01 (2011-10-30)
483
Figure 14-5 Upstream transmission of intra-board link aggregation
L2/L3 switch
LAG
LAG
S C U
Network Topology of the Upstream Transmission of Inter-Board Link Aggregation

Figure 14-6 shows the network topology of the upstream transmission of inter-board link aggregation. This type of network topology increases bandwidths (through the load balancing mode) and protects links and a board fault.The MA5600T/MA5603T can be dual-homed to two upper-layer devices. In such a scenario, the MA5600T/MA5603T must have a higher priority during LACP negotiation, that is, the MA5600T actively determines which upper-layer device functions an active device and which as a standby one.
Issue 01 (2011-10-30)
484
Figure 14-6 Network topology of inter-board link aggregation

L2/L3 switch L2/L3 switch Active L2/L3 switch Standby
LAG
Dual homing
LAG
LAG
S C U
S C U
(1)
(2)
If carriers provide different services for users in different periods, these services are connected to different MANs through different upstream ports on the OLT (here refers to the MA5600T/ MA5603T). The services include the Internet access service for common users, Internet private line service for enterprise users, NGN service for common users, VPN interconnection service for enterprise users, and IPTV service for common users. As shown in the figure, the OLT must provide at least four groups of ports because the OLT is connected to four types of upstream devices. If each inter-board aggregation group contains two ports, at least eight GE ports are required. In this way, both high bandwidth and high reliability are ensured. The ETHB and SPUA boards support the upstream transmission of inter-board link aggregation, and the SCUN and GIU boards support inter-board link aggregation. Inter-board aggregation transmits data upstream to the same Layer 2/Layer 3 device or upstream to different Layer 2/ Layer 3 devices in dual homing, as shown in Figure 14-7.
Issue 01 (2011-10-30)
485
Figure 14-7 Network topology of the upstream transmission of inter-board link aggregation
S C U
LAG LAG
S C U
Transmission upstream to the same Layer 2/Layer 3 device As shown in Figure 14-7 (1), one or multiple ports on either of two boards (of the same type) form a link aggregation group. At the same time, two or multiple ports of a networkside switch are configured as a link aggregation group. One aggregation group supports up to eight ports in any position and any sequence.
Dual homing to different Layer 2/Layer 3 devices, as shown in Figure 14-7 (2). A port (or multiple ports) on each board of two boards with the same type is aggregated into a link aggregation group. Two interconnected devices exist on the network side and LACP must be enabled on the corresponding ports. Two network-side devices work in the active/standby mode. In this application, the protect group needs not be configured. The multiple ports on two boards with the same type are added to both an aggregation group and a protect group. The data configurations of different ports in the aggregation group and protect group must be the same. The two upstream devices may not be added to a protect group. Their data configurations, however, must be the same. In this application, the protect group for two ports (they may exist on two boards) is supported.
Network Topology of Inter-Board Aggregation in a Subtending Network

In a subtending network, the SPUA, ETHB, and OPGD boards support inter-board aggregation. Figure 14-8 shows the network topology of inter-board aggregation in a subtending network.
Issue 01 (2011-10-30)
486
Figure 14-8 Network topology of inter-board aggregation in a subtending network
LAN switch A
LAN switch B
Standby
Active Link down
Standby
Active
LAG AN
Active/Standby Protection for Members in a Link Aggregation Group

Active/standby protection for members in a link aggregation group indicates that an access device is dual homed to two upstream devices and is configured with multiple links to each upstream device. These links are aggregated into a same aggregation group. The two groups of links to the two upstream devices work in the active-standby mode. When a link in the primary group is faulty or the available bandwidth of the primary group is lower than that of the secondary group, the secondary group serves as the primary group and the original primary group servers as the secondary group, as shown in Figure 14-9. Figure 14-9 Active/Standby protection for members in a link aggregation group
LAN switch Valid aggregation Valid aggregation LAG AN
Link down
Issue 01 (2011-10-30)
487
M+N Backup for Members in a Link Aggregation Group

M+N backup for members in a link aggregation group indicates that M+N links are configured as an aggregation group, where, M indicates the number of valid aggregated links in an aggregation group, and N indicates the backup links in an aggregation group. In addition, M is configured as the maximum number of links in an aggregation group. In these M aggregated links, if a port is faulty, a port in N links serves as the active port, as shown in Figure 14-10. Figure 14-10 M+N backup for members in a link aggregation group
L3 switch A
L3 switch B
L3 switch C
L3 switch D
G P B C
S C U
ETHB Optical splitter Aggregation group A Aggregation group B Aggregation group C Aggregation group D ONT ONT ONT ONT
14.1.8 Term, Acronyms, and Abbreviations

Term
Term Aggregation Explanation Two or more ports are bound and are used as one port. The ports in an aggregation group balance load and protect the link of each other.
Issue 01 (2011-10-30)
488
Term Inter-board aggregation
Explanation The ports in an inter-board aggregation group belong to different service boards to improve the reliability of the aggregation group. Two service boards that are bound to each other are used as one service board. Load balancing policy specifies which content of the packet determines the output port of an aggregation group, for example, whether the source MAC address or destination MAC address of the packets determines the output port.
Binding Load balancing policy

Acronyms and Abbreviations LAG LACP Full Spelling Link aggregation group Link Aggregation Control Protocol
14.2 Protection Group of Uplink Ports

After a protection group of upstream ports are configured, when the primary upstream port fails, the data can be transmitted in the upstream direction through the secondary upstream port. This topic provides introduction to this feature and describes the principle and reference documents of this feature.
14.2.1 Introduction
Definition
The protection group of upstream ports are a kind of group which contains the upstream ports of the active and standby control boards when the active and standby control boards are configured with two upstream ports respectively. In this way, the switching is performed according to the status of the upstream ports to guarantee that the uplinks work in the normal state.
Purpose
A protection group of upstream ports implements the port backup function of the devices at the NE end and provides the upstream backup of services provisioned to the users.
Issue 01 (2011-10-30)
489
The MA5600T/MA5603T supports the following specifications of a protection group of upstream ports: l Protection of upstream ports includes: Port status check Protection switching Service recovery l l The two upstream ports in a protection group can be on the same upstream board or on different upstream boards. The port types, however, must be the same. The ports in a protection group must be in the same aggregation group that cannot contain other ports.
14.2.3 Availability
Availability
l l Hardware support The SCUB board supports a protection group of upstream ports. License support A protection group of upstream ports is the basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Other
The SCUL board supports only the LACP mode, and the GIU upstream ports are required.
14.2.4 Principle
The protection group of upstream ports are implemented in the following two modes: l l PortState mode, which applies when the upstream ports are provided by the control boards. TimeDelay mode, which applies when the upstream ports are provided by the boards in the GIU slots.
PortState Mode
The active and standby SCUB boards connect to the active and standby PE devices at the upper layer respectively through the GE ports. Configure the GE ports of the active and standby SCUB boards into a protection group. Figure 14-11 shows the working principle of the PortState mode.
Issue 01 (2011-10-30)
490
Figure 14-11 Working principle of the PortState mode

Active PE Standby PE
Protection group
Standby
SCU
Active
1. 2.
When the working ports of the SCUB board fail, the system automatically checks the upstream ports of the standby SCUB board. If the number of upstream ports of the standby SCUB board that can work in the normal state is more than that of the ports of the active SCUB board that can work in the normal state, and the data of the active and standby SCUB boards is fully synchronized, the system switches the service to the standby SCUB board to implement protection switching of the upstream ports.
TimeDelay Mode
The TimeDelay mode is implemented by port check. Figure 14-12 shows the working principle of the TimeDelay mode. Figure 14-12 Working principle of the TimeDelay mode
G I U G I U
Active PE
Standby control board
The working process of the TimeDelay mode is as follows:
Active control board
Standby PE
Issue 01 (2011-10-30)
491
l l
When the active uplink works in the normal state, it connects to the active PE, and the standby uplink is disabled. When the uplink connecting to the active PE fails, and the active control board detects the failure, the active control board quickly enables the standby uplink. In this way, the service switches to the standby uplink, thus ensuring the backup of uplinks.
14.3 Smart Link and Monitor Link

The smart link is a solution that is applied in the dual-upstream-transmission network and provides reliable and high-efficiency backup and quick switching for the dual uplinks. The monitor link solution, as a supplementary to the smart link solution, is used to monitor the uplinks.
14.3.1 Introduction
Definition
The smart link is a solution that is applied in the network with dual uplinks and provides reliable and high-efficiency backup and quick switching for the dual uplinks.
Purpose
The network with dual uplinks is a common network application currently. In a network with dual uplinks, the redundant link can be blocked through the Spanning Tree Protocol (STP) or Rapid Spanning Tree Protocol (RSTP) and can provide the backup function. In this way, when the active link fails, traffic will be switched to the standby link. The preceding two solutions (STP and RSTP) can meet customers' requirements for redundancy backup from the perspective of the function, but cannot meet the requirements of many users for the performance. Thus, the smart link solution is applied to the access network. With this solution, redundancy backup for active and standby links and quick switching are implemented for a dual-homing network. This ensures high reliability and quick convergence. Meanwhile, as a supplementary to the smart link solution, the monitor link solution is introduced to monitor uplinks. This improves the backup function of the smart link solution.
Benefits
Benefits to Operators Implementation of the smart link solution and the monitor link solution provides high reliability for carriers' network.
l l l
Issue 01 (2011-10-30)
Active-standby working mode and load sharing working mode for the smart link feature Up to 16 monitor link groups Up to 16 downlinks in one monitor link group
14.3.3 Availability
Related NEs
The smart link and monitor link features, which are applied to the scenario of a network with dual uplinks (the network is connected to the upstream IP network through dual uplinks), is related to the OLT and the upstream network device. The upstream network device such as the router must support the smart link and monitor link features.
NOTE
The smart link and monitor link features are put forth by Huawei. Currently, only Huawei devices support this technology.
License Support
The smart link and monitor link features are basic features of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Version Support
Miscellaneous
When the device needs to process the FLUSH packet to update the MAC and ARP entries, the following conditions should be met: l l Set the port that receives the FLUSH packet as the receive port. The corresponding VLAN and check password of the local device must be the same as the VLAN and check password of the upstream network device.
14.3.4 Principle
14.3.4.1 Smart Link
This topic describes the working principle of the smart link feature.
Basic Concepts
A smart link protect group can work in the following two modes: l l
Issue 01 (2011-10-30)
Active-standby working mode Load sharing working mode

Figure 14-13 shows the active-standby working mode of a smart link protect group. Figure 14-13 Working mode of a smart link protect group
Smart Link group
1 Master port
2 Slave port
OLT
ACTIVE state STANDBY state
The following provides some concepts related to the smart link feature: l Smart link group A smart link group is also called an intelligent link group, which contains up to two ports, namely, one master port and one slave port. In normal conditions, only one port is in the ACTIVE state, and the other port is blocked and in the STANDBY state. When the port in the ACTIVE state fails, the smart link group automatically blocks the port, and switches the previously standby port to the ACTIVE state. As shown in Figure 14-13, ports 1 and 2 form a smart link group. l Master port The master port, which is also called the work port, is a port role in the smart link group. When both ports are in the STANDBY state, the master port is prevailed upon to switch to the ACTIVE state. The master port, however, is not always in the ACTIVE state. If the slave port is already in the ACTIVE state after link switching, the master port can only be in the STANDBY state even if its link recovers and the master port remains in this state until link switching the next time. For example, port 1 in the ACTIVE state in Figure 14-13 is the master port. l Slave port The slave port, which is also called the protect port, is a port role in the smart link group. When both ports are in the STANDBY state, the master is prevailed upon to switch to the ACTIVE state, and the slave port remains in the STANDBY state. The slave port is not always in the STANDBY state. It switches to the ACTIVE state after link switching occurs on the master port. Port 2 in Figure 14-13 is the slave port. l FLUSH packet After link switching occurs on the smart link group, the original forwarding entry is not applicable to the network with new topology, and the upstream convergence device needs
to update the MAC and ARP entries. In this case, the smart link group notifies the other devices on the network of updating the address table through sending the notification packet. This notification packet is the FLUSH packet. Figure 14-14 shows the load sharing working mode of a smart link protect group. Figure 14-14 Load sharing working mode of a smart link protect group
Smart link group
1 Master port
2 Slave port
OLT
ACTIVE state
In the load sharing working mode, the links of both ports are enabled. If both ports are normal, some services are transmitted through the master port and the others are transmitted through the slave port. When either of the ports fails, all the services are transmitted through the port in the normal state.
Working Principle
Figure 14-15 shows the working principle of the smart link feature.
Issue 01 (2011-10-30)
495
Figure 14-15 Working principle of the smart link feature
A fault occurs.
Send the FLUSH packet.
1 Master port OLT
2 Slave port
1 Master port OLT
2 Slave port
ACTIVE state STANDBY state
Normal working state The link of port 1 on the device is the active link and the link of port 2 is the standby link. In normal conditions, port 1 is in the ACTIVE state and port 2 is in the STANDBY state.
Switching When the link of port 1 fails, port 1 switches to the STANDBY state and port 2 switches to the ACTIVE state. When the original active link recovers from the fault, it remains in the blocked state and does not occupy bandwidth. This ensures stability of traffic.
Update When link switching occurs in the smart link group, the MAC and ARP entries on the devices on the network may be incorrect. Therefore, a new mechanism for updating the MAC and ARP entries is required. Currently, there are the following two mechanisms available for updating the MAC and ARP entries: The smart link device automatically updates the MAC and ARP entries through traffic. The smart link device sends the FLUSH packet through the new link to update the MAC and ARP entries. When the device supports the first mechanism, bidirectional traffic trigger is required. This is applicable to the scenario when the device interoperates with the device from other vendors. When the device supports the second mechanism, it requires the upstream device to identify the FLUSH packet of smart link and to update the MAC and ARP entries.
14.3.4.2 Monitor Link

This topic describes the working principle of the monitor link feature.
Issue 01 (2011-10-30)
496
Basic Concepts
Figure 14-16 Composition of a monitor link group
IP
Monitor link group 1 Uplink
Downlink 1 Up
Downlink 2 Up
Downlink n Up
The following describes some basic concepts related to the monitor link feature. l Monitor link group A monitor link group is composed of one uplink and several downlinks.
NOTE
The link in a monitor link group may not be a single link, but may be a certain type of link group. The uplink can be an aggregation group or protect group. The downlink can only be a single link. The status of the downlink changes according to the status of the uplink.
Uplink When the uplink in a monitor link group fails, it indicates that the monitor link group fails. In this case, the downlinks in the monitor link group will be blocked by force.
Downlink When a downlink in a monitor link group fails, it does not affect the uplink or the other downlinks.
Issue 01 (2011-10-30)
497
Working Principle
Figure 14-17 Working principle of the monitor link feature
Monitor link group
A fault occurs. 1 uplink 1 uplink
Monitor link group
Downlink 1 Up
Downlink 2 Up
Downlink n Up
Downlink 1 ShutDwon
Downlink 2 ShutDwon
Downlink n ShutDwon
After a monitor link group is configured, its uplink will be monitored in real time. Once the uplink fails, all the UP downlinks in the monitor link group will be blocked by force. When the uplink recovers from the fault, the downlinks are resumed. When the uplink is an aggregation group or protect group, the uplink is considered failed only when the entire aggregation group or protect group fails.

Figure 14-18 Network application of the smart link and monitor link features
Device 3 Device 1 1 Monitor link group 2 Smart link group 3 4
Device 2
OLT Traffic stream
Issue 01 (2011-10-30)
498
The MA5600T/MA5603T works as the OLT. Ports 3 and 4 on the MA5600T/MA5603T are added to a smart link group and work in the active-standby mode. Port 1 on device 1 is configured as the upstream port of the smart link group, and port 2 on device 1 the downstream port. In normal conditions, traffic is transmitted through the path highlighted in green. If the uplink of device 1 fails, the uplink in the smart link group will be blocked. In this case, on the MA5600T/ MA5603T, port 4 switches to the ACTIVE state because port 3 fails, and traffic is transmitted to device 2 and then to the upstream network. If the monitor link group is not configured on device 1, the channel between device 1 and the MA5600T/MA5603T is still in the ACTIVE state when the channel between device 1 and device 3 fails. Thus, the user traffic will be transmitted to device 1 from the MA5600T/MA5603T. As a result, the user cannot access the network.

Glossary
Table 14-6 Glossary of the terms related to the smart link and monitor link features Term Smart link Description A smart link is also called a backup link. It is applied to the scenario of a network with dual uplinks and provides reliable and high-efficiency backup and quick switching for the dual uplinks. The monitor link is a port association solution introduced as a supplementary to the smart link. After link switching occurs on the smart link group, the original forwarding entry is not applicable to the network of new topology. In this case, the FLUSH packet is transmitted to the upstream convergence device to notify the device to update the MAC and ARP entries.
Monitor link
Flush packet

None
14.4 MSTP
The Multiple Spanning Tree Protocol (MSTP) is compatible with STP and RSTP.
Issue 01 (2011-10-30)
499
14.4.1 Introduction
Definition
The Spanning Tree Protocol (STP) applies to a loop network to realize path redundancy through certain algorithms. STP also prunes a loop network into a loop-free tree network. This helps to avoid proliferation and infinite loop of packets in the loop network. The Rapid Spanning Tree Protocol (RSTP) is an improvement on STP. The rapidness of RSTP relies on the greatly shortened delay for the designated port and the root port to turn into the forwarding state in a certain condition. For details, see "Principle of RSTP" in "14.4.5 Principle." This helps to shorten the time for stabilizing the network topology. The Multiple Spanning Tree Protocol (MSTP) is compatible with STP and RSTP.
Purpose
Although STP can prune a loop network into a loop-free network, it fails to transit fast. Even a port in a point-to-point link or an edge port has to wait double Forward Delay time before it can turn into the forwarding state. RSTP features fast convergence; however, like STP, RSTP still has the following defects: l l All the bridges in a local area network (LAN) share a same spanning tree, and fail to block redundant links by VLAN. The packets of all the VLANs are forwarded along the same spanning tree. Therefore, load sharing of data traffic cannot be implemented between VLANs.
MSTP can be a remedy to the defects of STP and RSTP. It not only realizes fast convergence, but also enables traffic of different VLANs to be forwarded along their respective paths. This helps to provide a better load sharing mechanism for redundant links. MSTP sets VLAN mapping tables (relation tables between VLANs and spanning trees) to associate VLANs and spanning trees. MSTP divides a switching network into multiple regions. Each region contains multiple spanning trees, and each spanning tree is independent from others. MSTP prunes a loop network to a loop-free tree network to avoid proliferation and infinite loop of packets in the loop network. It also provides multiple redundant paths for data forwarding to realize load sharing of VLAN data during forwarding.
The MA5600T/MA5603T supports the following MSTP specifications: l l l l Compliance with IEEE std 802.1s Bridge Protocol Data Unit (BPDU) protection Root protection Loop protection

The following lists the reference documents of MSTP: l
Issue 01 (2011-10-30)
IEEE Std 802.1d, 1998 Edition, Spanning Tree Protocol

l l
IEEE Std 802.1w-2001, Rapid Spanning Tree Protocol IEEE Std 802.1s-2002, Multiple Spanning Tree Protocol
14.4.4 Availability
License Support
The MSTP feature is the basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Version Support
Feature Dependency
Due to difference in protocols, RSTP and MSTP shall comply with the following limitations when cooperating to realize fast transition: l l The bridge running MSTP works as the upstream device. The bridge running RSTP works as the downstream device.
Otherwise, when the network topology changes, fast transition of a port cannot be realized.
Hardware Support
The boards that support the MSTP feature are the SCUB board, the SCUN board, the SPUA board, the OPGD board, the ETHB board, and the board in the GIU slot.
14.4.5 Principle
Principle of STP
STP determines the topology of a network by transmitting a certain special message (configuration message as defined in IEEE 802.1D) between bridges. A configuration message contains sufficient information to enable the bridge to complete the calculation of the spanning tree. The following defines the designated port and the designated bridge: l For a bridge (such as bridge A), the designated bridge is a bridge that is directly connected to bridge A and forwards data packets to bridge A. The designated port is the port in the designated bridge through which the data packets are forwarded to bridge A.
Issue 01 (2011-10-30)
For a LAN, the designated bridge is a bridge that forwards data packets to the LAN. The designated port is the port in the designated bridge through which the data packets are forwarded to the LAN.
Figure 14-19 Schematic drawing of designated bridge and designated port

Switch A Priority: 0
AP1
AP2 CP1 Switch C Priority: 2
BP1 Switch B Priority: 1 BP2
CP2
As shown in Figure 14-19: l l l AP1, AP2, BP1, BP2, CP1, and CP2 are ports in Switch A, Switch B, and Switch C respectively. Switch A forwards data to Switch B through port AP1, and then the designated bridge of Switch B is Switch A, and the designated port is port AP1 in Switch A. Switch B and Switch C are connected to the LAN. If Switch B forwards data packets to the LAN, the designated bridge of the LAN is Switch B, and the designated port is port BP2 in Switch B.
In STP, the configuration message is forwarded as follows: 1. 2. In network initialization, all the bridges work as the root bridge of the spanning tree. The designated port of a bridge takes the hello time as the interval for sending its configuration messages. If the port that receives the configuration message is a root port, the bridge increases the message age contained in the configuration message by degrees and enables the timer to time the configuration message. If a path fails, the root port on this path receives new configuration messages no longer, and the old configuration messages are discarded due to timeout. This results in recalculation of the spanning tree. A new path then is created to replace the faulty path and recover the network connectivity.
3.
The new configuration message upon the recalculation, however, will not immediately spread throughout the entire network. In this case, the old root port and designated port that fail to discover the topology change will forward their data along the old paths. If the selected root port and designated port forwards data immediately, a temporary loop may be created. Therefore, STP adopts a state transition mechanism. That is, the root port and the designated port have to experience a transition state before they can re-forward data. The transition state
turns into the forwarding state upon Forward Delay. This delay guarantees that the new configuration message has spread throughout the entire network.
Defects of STP
l In case of topology change or link failure, a port has to wait double Forward Delay time before it can turn from the blocking state to the forwarding state. Therefore, in case of topology change, double Forward Delay time (at least scores of seconds) is required to restore the network connectivity. The entire bridged LAN uses a single spanning tree instance. Therefore, when the network is large, a longer convergence time may be required or the topology changes frequently.
Principle of RSTP
RSTP is an improvement on STP. The rapidness of RSTP relies on the greatly shortened delay for the designated port and the root port to turn into the forwarding state in a certain condition. This helps to shorten the time for stabilizing the network topology. In comparison with STP, RSTP improves in the following aspects: l First improvement: The alternate port and backup port are set for rapid switching of the root port and designated port. When the root port fails, the alternate port quickly switches to the new root port and turns into the forwarding state without delay. When the designated port fails, the backup port quickly switches to the new designated port and turns into the forwarding state without delay. l Second improvement: In a point-to-point link connected with two switching ports, a designated port turns into the forwarding state without delay after one handshake with the downstream bridge. In a shared link connected with at least three bridges, the downstream bridge does not respond to the handshake request sent from the upstream designated port, and the designated port has to wait double Forward Delay time before it turns into the forwarding state. l Third improvement: A port that is directly connected to a terminal and is not connected to any other bridge is defined as an edge port. The edge port can directly turn into the forwarding state without delay. Because a bridge does not know whether a port is directly connected to a terminal, the edge port must be configured manually. The bridges that adopt RSTP are compatible with the bridges which adopt STP. The bridges that adopt RSTP can identify both STP and RSTP packets and apply them to calculation of the spanning tree.
Defects of RSTP
Although RSTP features fast convergence, like STP, RSTP still has the following defects: All the bridges in a LAN share a same spanning tree, and thus the packets of all the VLANs cannot be forwarded equally. Furthermore, the packets of some VLANs cannot be forwarded.
Principle of MSTP
MSTP can compensate for the defects of STP and RSTP. It not only realizes fast convergence, but also enables traffic of different VLANs to be forwarded along their respective paths. This helps to provide a better load sharing mechanism for redundant links. MSTP sets VLAN mapping tables (relation tables between VLANs and spanning trees) to associate VLANs and spanning trees. MSTP divides a switching network into multiple regions. Each region contains multiple spanning trees, and each spanning tree is independent of one another. Multiple spanning trees can run on each bridge to forward the packets of different VLANs. MSTP divides the entire Layer 2 network into multiple spanning tree (MST) regions. These regions and the other bridges and LANs are connected into a single common spanning tree (CST). Multiple spanning trees are created in a region through calculation. Each spanning tree is defined as a multiple spanning tree instance (MSTI). MSTI 0 is defined as an internal spanning tree (IST). MSTP connects all bridges and LANs with a single common and internal spanning tree (CIST) which consists of the CST and the IST. Like RSTP, MSTP calculates the spanning tree according to the configuration message. The configuration message, however, contains the message of MSTP on the bridge. l Calculation of CIST Select a bridge with the highest priority within the entire network as the CIST root by comparing the configuration messages. In each MST region, MSTP creates an IST through calculation. Meanwhile, MSTP regards each MST region as a single bridge, and then creates a CST between regions. The CST and the IST forms the CIST that connects all the bridges in a bridge network. l Calculation of MSTI In an MST region, MSTP creates different MSTIs for different VLANs according to the mapping relation between the VLANs and the spanning tree instances. Each spanning tree is calculated independently. The process is similar to that in which the RSTP calculates the spanning tree.
Implementation of MSTP on the MA5600T/MA5603T

MSTP is compatible with STP and RSTP. The bridges that adopt MSTP can identify both STP and RSTP packets and apply them to calculate spanning tree. Besides the basic functions of MSTP, the MA5600T/MA5603T provides some special functions, such as: l BPDU protection For an access device, the access port is generally connected to a terminal (such as a PC) or file server. In this case, the access port is set to an edge port for the purpose of fast transition. When receiving a configuration message (BPDU), the edge port switches to a non-edge port automatically, the spanning tree is re-calculated and the topology changes accordingly. In normal conditions, an edge port cannot receive STP configuration messages. If the bridge is maliciously attacked by forged configuration messages, the network will be attacked. The BPDU protection function can prevent such network attacks. After the BPDU protection function is enabled on the MA5600T/MA5603T, if an edge port receives a configuration message, the system shuts down the edge port, and notifies the network management system of the related information. Only network administrators can enable the port that is shut down.
It is recommended that you enable the BPDU protection function on the MA5600T/ MA5603T which is configured with an edge port. l Root protection Because of wrong configurations by the maintenance personnel or malicious network attacks, a legal root bridge in the network may receive a configuration message with a higher priority. In this case, this root bridge may become a non-root bridge and the topology changes accordingly. Such illegal change results in transfer of traffic in high-speed links to low-speed links, thus causing network congestion. The root protection function is a solution to this problem. When the root protection function is enabled for a port, the port is always a designated port. If the port receives a configuration message with a higher priority, and is to become a nondesignated port, the port will turn into the listening state and will not forward packets (that is, the link connected to the port is disconnected). If the port does not receive a configuration message of a much higher priority within a certain long period of time, the port will turn into the normal state. l Loop protection A bridge maintains the states of the root port and other blocked ports by continuously receiving BPDUs from the upstream bridge. In case of link congestion or failure, these ports fail to receive BPDUs from the upstream bridge. For this reason, the bridge will re-select its root bridge. The previous root bridge switches to the designated port, and the blocked ports turn to the forwarding state. As a result, loops are created in the switching network. The loop protection function is a solution to this problem. After receiving the BPDUs (excluding the TCN packets) again, a port under loop protection normally processes the packets, selects the role, and resets the forwarding state of the port. The port is not always in the blocked state. When the loop protection function is enabled, if the root port switches to a non-root port, it will turn into the discarding state, and the blocked ports will remain in the discarding state. Therefore, no packets are forwarded, and no loop is created in the network.
NOTE
The three protection functions conflict with each other.
14.5 RRPP
Rapid Ring Protection Protocol (RRPP) is a link-layer protocol specially used for protecting Ethernet ring networks.
14.5.1 Introduction
Definition
Most metropolitan area networks (MANs) and enterprise networks adopt a ring topology to provide high reliability. In a ring topology, the failure of any node on the ring does not affect services. The following introduces some known ring network technologies. l SDH/SONET ring Synchronous digital hierarchy (SDH) and synchronous optical network (SONET) are ring technologies widely used in current transport networks and support single ring and multiple
rings. SDH/SONET feature high reliability because they provide an automatic protection switching (APS) self-healing mechanism in case of a fault. Due to the point-to-point (P2P) and circuit-switched design, in SDH/SONET ring networks, bandwidth is fixedly allocated and reserved on the P2P links between nodes. Thus bandwidth cannot be adjusted according to actual traffic condition in the networks. This hampers the efficient utilization of bandwidth and makes it different for the SDH/SONET networks to adapt to IP data service, which has the bursty characteristics. Broadcast and multicast packets in SDH/SONET ring networks are fragmented and transmitted as multiple unicast packets, which is a serious waste of bandwidth. In addition, a redundant bandwidth as high as 50% is required for the APS feature. In this case, a flexible selection mechanism is not available. l RPR ring Resilient packet ring (RPR) is a MAC layer-based protocol researched and standardized by the IEEE 802.17 working group and RPR Alliance. RPR is used on ring topologies. The RPR design targets at a close-loop, P2P, and MAC layer-based logical ring topology. Viewed from the physical layer, an RPR is a set of P2P links; from the data link layer, RPR is more like a broadcast medium network similar to Ethernet. RPR requires dedicated hardware support and involves complicated fairness algorithms. l STP ring Spanning Tree Protocol (STP) is also a standard ring protection protocol developed by IEEE and has been in wide application. However, STP rings in actual application are restricted by the network scale, and the convergence time is also subject to the network topology. The convergence time is not desirable when the network diameter is large. In this case, STP rings may fail to carry data that has high requirements on transmission quality. Rapid Ring Protection Protocol (RRPP) is a link-layer protocol dedicated to Ethernet ring protection. RRPP is free from the problems above, such as bandwidth waste, dedicated hardware support, and slow convergence. On a complete Ethernet ring RRPP protects against broadcast storms caused by data loops. When the Ethernet ring has a link break, RRPP can rapidly recover the communication channels between the nodes on the ring.
Purpose
To enable faster convergence and mitigate the impact of network scale on the convergence speed, Huawei develops RRPP, a link-layer protocol specially for Ethernet ring protection. Compared with other Ethernet ring network technologies, RRPP has the following advantages: l l l l Provides fast topology convergence within 50 ms. Supports a convergence duration independent from the number of nodes on the ring. RRPP applies to networks with a larger diameter. Prevents broadcast storms caused by data loops when the Ethernet ring is complete. Rapidly starts the backup link to recover the communication channel between the nodes on the Ethernet ring when the ring has a link break.
The specifications of the RRPP feature are as follows: l The system supports only one RRPP domain, and supports only the RRPP single-ring network topology.
Issue 01 (2011-10-30)
If one link on the RRPP ring fails, the service interruption duration on the RRPP ring is within 200 ms.

The following lists the reference standards and protocols of this feature: l l RRPP (by Huawei) Ethernet Automatic Protection Switching (EAPS)
14.5.4 Availability
License Support
This feature is provided without a license.
Version Support
Table 14-8 lists the versions that support the RRPP feature. Table 14-8 Base version required for the RRPP feature Product MA5600T/MA5603T Version V800R008C01
Hardware Support
The optical ports on the GIU/SCU/ETHB board support the RRPP protocol when the ports are used for upstream transmission.
Limitations
l l l The RRPP protocol cannot be enabled at the same time with the PS, LACP, or MSTP protocol. Currently, the RRPP feature is supported by upstream Ethernet ports but is not supported by xPON ports. When working in the active/standby mode, the SCU control boards do not support the Ethernet ports respectively on the active and standby control boards to function as RRPP ports. Only upstream ports support configurable network-side roles for RRPP. The control VLAN must not run other Layer 2 or Layer 3 services than the RRPP service. Ethernet optical ports support the RRPP protocol. When the upstream Ethernet ports of the system are electrical ports, RRPP supports protection switching on the basis of seconds. When the system goes upstream through the ETHB board and RRPP is enabled in the system, the system does not support multicast service. When the RRPP ring is activated, multicast upstream port and multicast subtending port need not be configured on the upstream port. The configuration sequence of the nodes on
l l l l l
Issue 01 (2011-10-30)
an RRPP ring is as follows: First, configure all transit nodes and activate the transit nodes; then, configure the master node and activate the master node. l Suppression of unknown unicast packets affects the recovery time of RRPP ring switching.
14.5.5 Principle
14.5.5.1 RRPP Network Topology
An RRPP domain has the following constituents, as shown in Figure 14-20. Figure 14-20 RRPP domain
RRPP domain Transit node B Primary port Master node A
Secondary port RRPP ring
Transit node C
Transit node D
RRPP Domain
An RRPP domain is uniquely identified by an integral ID, and it consists of a set of interoperated switches that are configured with the same domain ID and the same control VLANs. One node supports only one domain. An RRPP domain mainly includes the following components: l l l l
Issue 01 (2011-10-30)
RRPP ring Control VLAN Master node Transit node

RRPP Ring
An RRPP ring physically corresponds to a ring-connection Ethernet topology. An RRPP domain is built on multiple interconnected RRPP rings, among which there is a primary ring and the rest are secondary rings. The primary ring and secondary rings are identified by levels specified during configuration. The primary ring is identified by level 0 and secondary rings by level 1. An RRPP ring is also identified by an integral ID. Currently, the MA5600T supports only one RRPP ring in an RRPP domain.
Control VLAN
Each RRPP domain has two control VLANs. One is the primary control VLAN and the other the secondary control VLAN. The protocol packets of the primary ring are transmitted in the primary control VLAN, and the protocol packets of the secondary ring are transmitted in the secondary control VLAN. During configuration, you only need to specify the ID of the primary control VLAN, and a VLAN whose ID is larger than the primary control VLAN by 1 will serve as the secondary control VLAN. The ports of the primary control VLAN and the secondary control VLAN must not be configured with IP addresses. The RRPP port on the primary ring must belong to the primary control VLAN and the secondary control VLAN at the same time; the RRPP port of the secondary ring only needs to belong to the secondary control VLAN. The primary ring is treated as a logical node of the secondary rings and the packets of the secondary rings are transparently transmitted by the primary ring. The packets of the primary ring are transmitted only within the primary ring and are not transmitted to the secondary rings.
Master Node
The master node is the policy-making and controlling node on an RRPP ring. Each RRPP ring must have one and only one designated master node. The master node initiates the polling mechanism (a mechanism for actively checking the ring status), and also determines and implements the policies after the network topology changes. A master node has three states: l l Complete state: If the master node can receive its own hello packets on the secondary port, it indicates that the ring is complete. In this case, the ring is in the complete state. Failed state: If the master node does not receive its own hello packet within a specified time, the master node regards that there is a link-down on the ring network. In this case, the master node opens its secondary port for forwarding data and the ring is in the failed state. Unknown state: When the RRPP ring is not enabled, the ring is in the unknown state.
Transit Node
All nodes except the master node on a ring can be called transit nodes. Transit nodes monitor the status of the RRPP links that are directly connected to them, and notify the master node of the link state change. Then the master node will decide how to handle the changes. A transit node has three states:
l l l
Link-up state: The primary port and secondary port of the transit node are up. Link-down state: The primary port or secondary port of the transit node is down. Preforwarding state (temporarily blocked state): The primary port or secondary port of the transit node is blocked. When the link of the port of a link-down transit node goes up, the transit node changes to the preforwarding state and blocks the recovered port. When the transit node in the preforwarding state receives a packet instructing an unblock, or when the fail timer of the domain where the transit node is located expires, the transit node unblocks the blocked port.
Primary Port and Secondary Port

The master node and transit nodes all connect to an Ethernet ring through two ports. Of the two ports, one is the primary port and the other the secondary port. The port roles are userconfigurable. The primary port and secondary port of the master node function differently. The master node periodically transmits ring-check packets through its primary port. If the master node can receive the packets on its secondary port, it indicates that the RRPP ring network where the master node is located is complete. In this case, it is necessary for the master node to block its secondary port to prevent a data loop. On the contrary, if the master node does not receive the ring-check packets within a specified time, it indicates that the ring network is faulty. In this case, it is necessary for the master node to unblock the secondary port to ensure normal communication between all nodes on the ring. The primary port and secondary port of a transit node function the same. The port roles of a transit node are also user-configurable. In the case of a block, the secondary port on the master node of a primary ring is blocked not only from data packets but also from the protocol packets of the secondary rings. Likewise, in the case of a block, the RRPP ports (including the primary port and the secondary port) on the transit node of a primary ring are blocked from both data packets and the protocol packets of secondary rings. In the case of an unblock, these ports are opened for the packets.
RRPP Domain Timer

A domain can be configured with a domain timer; different nodes on a ring can also be configured with different domain timers. Domain timers have two types: hello timer and fail timer. l l l The hello timer sets the interval for sending hello packets. By default, the length of a hello timer is 1s and that of a fail timer is 3s. The range of a hello timer is 1-10s, and the range of a fail timer is 3-30s. The configured length of the fail timer must be at least three times the length of the hello timer.
14.5.5.2 RRPP Packet Packet Type

Table 14-9 lists the types of RRPP packets.
Issue 01 (2011-10-30)
510
Table 14-9 Types of RRPP packets Packet Type HEALTH (HELLO) Description Health-check packet. It is sent by the master node for checking the ring integrity of the network. Link-down packet. It is sent by the transit node, edge node, or auxiliary edge node whose direct-connection link is down. The node sends this packet to inform the master node that a link on the ring is down and the physical ring disappears. Flush-FDB packet. It is sent by the master node to inform the transit node, edge node, or auxiliary edge node to flush their respective MAC address forwarding table. Ring recovery flush-FDB packet. It is sent by the master node to inform the transit node, edge node, or auxiliary edge node to flush their respective MAC address forwarding table, at the same time instructing the transit node to unblock the port that has been temporarily blocked.
LINK-DOWN
COMMON-FLUSH-FDB
COMPLETE-FLUSH-FDB
RRPP Packet Format

Figure 14-21 shows the format of an RRPP packet.
Issue 01 (2011-10-30)
511
Figure 14-21 RRPP packet format

0 7 8 15 16 23 24 31 32 39 40 47
Destination MAC Address (6 bytes) Source MAC Address (6 bytes) EtherType DSAP/SSAP 0x00bb RRPP_VER RRPPTYP E PRI CONTROL 0x99 0x0b VLAN ID Frame Length OUI = 0x00e02b RRPP Length Ring ID
Domain ID
0x0000
SYSTEM_MAC_ADDR (6 bytes) HELLO_TIMER FAIL_TIMER 0x0000
0x00
LEVEL
HELLO_SEQ RESERVED(0x000000000000) RESERVED(0x000000000000) RESERVED(0x000000000000) RESERVED(0x000000000000) RESERVED(0x000000000000) RESERVED(0x000000000000)
The description of each field in the packet is as follows: l l l l l l l l l l l l l l Destination MAC Address: 48 bits. It indicates the destination MAC address of the packet. Source MAC Address: 48 bits. It indicates the source MAC address of the packet. EtherType: 8 bits. It is the packet encapsulation type field and is always 0x8100 (indicating tagged). PRI: 4 bits. It indicates the class of service (CoS) priority. VLAN ID: 12 bits. It indicates the ID of the VLAN to which the packet belongs. Frame Length: 16 bits. It indicates the Ethernet frame length. DSAP/SSAP: 16 bits. It indicates the destination service access point/source service access point. CONTROL: 8 bits. OUI: 24 bits. RRPP_LENGTH: 16 bits. It indicates the length of the RRPP protocol data unit. RRPP_VERS: 16 bits. It indicates the RRPP version. DOMAIN_ID: 16 bits. It indicates the ID of the RRPP domain to which the packet belongs. RING_ID: 16 bits. It indicates the ID of the RRPP ring to which the packet belongs. SYSTEM_MAC_ADDR: 48 bits. It indicates the bridge MAC address of the node sending the packet. HELLO_TIMER: 16 bits. It indicates the timeout time of the hello timer used by the node sending the RRPP packet. The timer is in the unit of second.
Issue 01 (2011-10-30)
l l
FAIL_TIMER: 16 bits. It indicates the timeout time of the fail timer used by the node sending the RRPP packet. The timer is in the unit of second. HELLO_SEQ: 16 bits. It indicates the sequence number of the hello packet.
14.5.5.3 RRPP Basic Principle Polling Mechanism

In the polling mechanism, the master node transmits the HELLO packet from its primary port periodically to check the ring network. After transmitting the HELLO packet, if the master node can receive this packet on its secondary port, it indicates that the ring network is complete. If the master node cannot receive this packet within the specified period, the master node considers that a link fault occurs on the ring network and unblocks its secondary port and allows it to forward packets. This is the basic mechanism for RRPP. Figure 14-22 Polling mechanism implementation
Master node Primary port Hello
Transit node
Secondary port
Transit node Hello protocol packet Data packet
Transit node
The polling mechanism is a mechanism that the master node of the RRPP ring actively checks the health status of the ring network. Its process is as follows: 1. 2. The master node transmits the HELLO packet periodically from its primary port according to the value of the HELLO timer. The HELLO packet is transmitted over the ring network by passing every transit node on the ring network. l After transmitting the HELLO packet, if the master node can receive this packet on its secondary port before the Fail timer times out, the master node considers that the ring network is complete.
l After transmitting the HELLO packet, if the master node cannot receive this packet on its secondary port after the Fail timer times out, the master node considers that the ring network is faulty. After receiving the HELLO packet that is sent from the master node in the Failed state on the secondary port, the master node performs the following operations: 1. 2. 3. 4. Changes itself to the Complete state. Blocks its secondary port. Flushes the FDB. Transmits packets from its primary port to notify all the transit nodes of unblocking the temporarily blocked port and flushing their FDBs.
Mechanism of Link State Change Notification

Figure 14-23 shows the mechanism of link state change notification. 1. 2. 3. If a link fault occurs over the ring network, the state of the port connecting to the link is changed to Down. The transit node transmits the LINK-DOWN packet actively and immediately to the master node to notify the master node of the link state change. After receiving the LINK-DOWN packet, the master node considers that the ring network is faulty and unblocks its secondary port. At the same time, the master node transmits the packets to other transit nodes to notify them of flushing their FDBs. After other transit nodes flush the FDB, data streams are switched to the normal links.
4.
Figure 14-23 Link fault

Master node Primary port Transit node LINK-DOWN
Secondary port LINK-DOWN
COMMON-FDB LINK-DOWN COMMON-FDB
COMMON-FDB
Transit node Protocol packet Data packet
Transit node
Figure 14-24 shows the mechanism of link recovery notification. 1.

Issue 01 (2011-10-30)
If a link fault is rectified, the port of the transit node changes to the Forwarding state.
2. 3. 4.
This transit node temporarily blocks the port whose fault is rectified; however, the HELLO packet transmitted from the master node can pass the temporarily blocked port. After receiving the HELLO packet that is sent from the master node on the secondary port, the master node considers that the ring network recovers to the health state. The master node blocks the secondary port and transmits the packet to other transit nodes to notify them of unblocking the temporarily blocked ports and flushing their FDBs.
Figure 14-24 Link recovery
Master node Primary port HELLO
Transit node
Secondary port HELLO
COMPLET-FDB COMPLET-FDB HELLO
COMPLET-FDB
COMPLET-FDB
Transit node preforwarding Protocol packet Data packet
HELLO
Transit node preforwarding
Issue 01 (2011-10-30)
515
14.5.5.4 Working Principle of RRPP Ring Polling

Figure 14-25 RRPP ring in the complete state
P Master Hello protocol packet Data packet
S Block
P Primary port S Secondary port
1. 2. 3.
When all links in the entire ring network are up, the RRPP ring is in a healthy state. The state of the master node reflects the health condition of the entire ring network. When the ring network is healthy, the master node needs to block its secondary port to prevent data loops. Data loops will cause a broadcast storm. The master node periodically sends hello packets from its primary port. The hello packets traverse the transit nodes and finally return to the master node by its secondary port.
Link-down Alert
1. When the RRPP port of a transit node has a link-down, the transit node notifies the master node by a link-down packet, as shown in Figure 14-26.
Issue 01 (2011-10-30)
516
Figure 14-26 Link-down alerting of a transit node

Link Failure
P Master Link-down protocol packet Data packet
S Block
2.
After receiving the link-down packet, the master node immediately changes from the complete state to the failed state and unblocks its secondary port. The master node provides a polling mechanism which attends to the event that the linkdown packet is lost during transmission. If the master node does not receive hello packets on its secondary port after the fail timer expires, the master node also considers that there is a ring network failure. Such a condition is processed in the same way as the transit node actively reporting link-down.
3.
Since the network topology is changed, to prevent incorrect direction of packets, the master node also needs to flush its FDB table and send the COMMON-FLUSH-FDB packet from its primary port and secondary port to all transit nodes so that the transit nodes can flush their FDB tables. Figure 14-27 illustrates the process. Figure 14-27 Master node changing to the failed state
Link Failture
P Master COMMON-FLUSH-FDB protocol packet Data packet
Issue 01 (2011-10-30)
517
Link Restoration
1. 2. When the RRPP port of the transit node recovers, the transit node changes to the preforwarding state and blocks the recovered port. The master node periodically sends hello packets from its primary port. After all the faulty links on the ring network recover, the master node will receive the hello packets on its secondary port again. After the master node receives the hello packets that are sent by itself, the master node will first changes back to the complete state and block its secondary port. The master node sends the COMPLETE_FLUSH_FDB packet from its primary port to notify all transit nodes to flush their FDB tables. Figure 14-28 illustrates the process. Figure 14-28 Ring network restoration
3. 4.
P Master COMPLETE-FLUSH-FDB protocol packet Data packet
S Block

A single-ring topology consists of only one ring. Therefore, only one RRPP domain and one RRPP ring need to be defined. The single-ring topology responds quickly in case of a network topology change and thus provides for a shorter convergence duration. This meets the requirements of a network that contains only one ring.
Issue 01 (2011-10-30)
518
Normal Links
Figure 14-29 Single-ring network application (for normal links)
RRPP domain Transit 2 ADSL2+/SHDSL /VDSL2 modem Transit 1 RRPP Master Master Block S ONU Transit 3 ONT Data packet LAN switch P
POTS
Figure 14-29 shows an RRPP single-ring topology. In normal conditions, data flows travel the "Transit 1 -> Transit 2 -> Master" route on the RRPP ring. If the link between Transit 1 and Transit 2 fails, the data flows will be rerouted on the RRPP ring.
Faulty Links
Figure 14-30 Single-ring network application (for faulty links)
RRPP domain ADSL2+/SHDSL/ VDSL2 modem Transit 1 Transit 2 P POTS RRPP Master Master S ONU Transit 3 ONT Data packet Packet for updating MAC address and ARP entries Link-down packet LAN switch
As shown in Figure 14-30, when the link between Transit 1 and Transit 2 fails, the master node will receive a link-down notification and will immediately unblock its secondary port. Now, the network topology is changed and the original MAC address tables of the nodes cannot correctly guide the forwarding any more. In this case, Layer 2 and Layer 3 service streams will be interrupted. After unblocking its secondary port, the master node immediately informs all other nodes (transit nodes) on the ring to re-learn MAC address entries and ARP entries. After entries are re-learned, Layer 2 and Layer 3 service streams on the RRPP ring will be rerouted to "Transit 1 -> Transit 3 -> Master".
14.5.7 Glossary, Acronyms and Abbreviations

Glossary
Term RRPP domain Explanation An RRPP domain is uniquely identified by an integral ID, and it is composed of a set of interoperating switches that are configured with the same domain ID and are in the same control VLAN. Each RRPP ring physically corresponds to an Ethernet that is in a ring topology. An RRPP ring is also identified by an integral ID. A control VLAN is a comparative concept to a data VLAN. In an RRPP domain, a control VLAN is used for only transmitting RRPP protocol packets. A master node initiates the polling mechanism (a mechanism for actively checking the ring status), and also determines and implements the policies after the network topology changes. A transit node monitors the status of the RRPP links that are directly connected to the node, and notifies the master node of the link state change. Then the master node will decide how to handle the changes. The master node and transit nodes all connect to the Ethernet ring through two ports. Of the two ports, one is the primary port and the other the secondary port. The port roles are user-configurable. The primary port and secondary port of the master node function differently. A master node sends hello packets from its primary port. If the master node can receive the hello packets from its secondary port, it indicates that the RRPP ring where the master node is located is complete. In this case, the master node should block its secondary port to prevent a data loop. On the contrary, if the master node does not receive the hello packets within a specified time, it indicates that the ring is faulty. In this case, the master node should unblock its secondary port to ensure normal communication between all nodes on the ring. The primary port and secondary port of a transit node function the same.
RRPP ring Control VLAN
Master node
Transit node
Primary/Secondary port

Acronym/Abbreviation RRPP MSTP STP FDB Full Spelling Rapid Ring Protection Protocol Multiple Spanning Trees Protocol Spanning Tree Protocol Forwarding Database
Issue 01 (2011-10-30)
520
14.6 BFD
14.6.1 Overview
Purpose
Bidirectional forwarding detection (BFD) fast detects communications faults between systems and notify upper-layer applications of those faults.
Description
To minimize the impact of a fault on services and improve network availability, a network device must fast detect communications faults between adjacent devices so that the upper layer protocol can resolve the issue and recover services. Currently, the existing detection mechanisms are as follows: l Hardware detection: For example, Synchronous Digital Hierarchy (SDH) alarms are used to detect link faults. Hardware detection can fast detect a fault; however, not all media support this hardware detection mechanism. Slow Hello: Usually refers to the Hello mechanism used by a routing protocol. The slow Hello mechanism can detect a fault in seconds. For example, in high-speed gigabit rate data transmission, a detection time of more than one second results in a large data loss. Delaysensitive services, like voice, cannot function with more than a one second delay. Other detection mechanisms: Different protocols or manufacturers may provide their own proprietary detection mechanisms; however, deploying proprietary detection mechanisms on different systems can be very difficult.
BFD has been developed to supplement other detection mechanisms. BFD provides the following features: l l Low-cost fast fault detection for channels between adjacent forwarding engines. Faults can be detected on interfaces, data links, and forwarding engines. A single mechanism capable of real-time detection over any media, at any protocol layer.
l l l l The Control board can be configured with up to 32 BFD sessions. Supports a minimum packet transmit interval of each BFD session: 10 ms; maximum interval: 10s. Each BFD session can be configured with the multiple of 3-50. Supports a minimum detection time of each BFD session: 30 ms; maximum detection time: 27s.
14.6.3 References
The references of this feature are as follows:
Document RFC5880 RFC5882 RFC5883 RFC5881
Description Bidirectional Forwarding Detection Generic Application of BFD BFD for Multihop Paths BFD for IPv4 and IPv6 (Single Hop)
Remarks -
14.6.4 Key Concepts

BFD detects communications faults between forwarding engines, specifically the connectivity of a data protocol on a path between systems. The path can be a physical link, a logical link, or a tunnel. BFD can be regarded as a service provided by the system. l l Upper layer applications provide BFD with parameters, such as the detection address and the detection time. BFD creates, deletes, or modifies a BFD session according to this information and notifies the upper layer applications of the session status.
BFD offers the following features: l l Low-cost, fast detection of path faults between adjacent forwarding engines A single mechanism capable of detection over any media, at any protocol layer, facilitating an integrated detection mechanism.
The following sections describe basic BFD concepts, including the BFD detection mechanism, detected link types, BFD session modes, and session management.
BFD Detection Mechanism

In the BFD detection mechanism, two systems set up a BFD session, and periodically send BFD control packets along the path between them. If one system does not receive BFD control packets within a specified period, the system concludes that a fault has occurred on the path. BFD control packets are encapsulated in UDP packets. In the initial phase of a BFD session, both systems negotiate with each other using parameters in BFD control packets, such as discriminators, expected minimum intervals for sending and receiving BFD control packets, and local BFD session status. When negotiations are successful, the two systems send BFD control packets to each other at the negotiated intervals. To meet fast detection requirements, the BFD draft specified that BFD control packets must be sent and received at intervals expressed in microseconds. However, BFD-enabled devices of most manufacturers can only process BFD control packets within milliseconds due to limited processing capabilities. Therefore, the configured interval is expressed in milliseconds and is converted to microseconds during internal processing. The minimum detection time that the MA5600T/MA5603T supports is 30 milliseconds. BFD provides the following detection modes:
Asynchronous mode: The main mode is asynchronous mode. In asynchronous mode, two systems periodically send BFD control packets to each other. If one system fails to receive packets consecutively, the BFD session is considered Down. Query mode: The second mode is the query mode. If multiple BFD sessions exist in a system, periodically sending BFD control packets can draw significant system resources. To prevent this, you can use the query mode. In query mode, after a BFD session is set up, the system does not periodically send BFD control packets, but detects the connectivity through another mechanism (such as the Hello mechanism of a routing protocol or the hardware detection mechanism), reducing system resources used by the BFD session.
An auxiliary function of the two modes is the Echo function. When the Echo function is activated, a BFD control packet is sent as follows: The local system sends a BFD control packet and the remote system sends the BFD control packet back through the forwarding channel. If consecutive Echo packets are not received, the BFD session is declared Down. The Echo function can work in asynchronous or query mode. At present, only the passive Echo function is supported.
Link Types Detected by BFD

l VLANIF BFD sessions used to detect a VLANIF interface and VLAN member interfaces are independent from each other and can detect these interfaces at the same time.
BFD Session Modes

A BFD session can be set up in the following modes: BFD differentiates sessions by My Discriminator and Your Discriminator in the control packets. The main difference in establishment of static and dynamic BFD sessions is that My Discriminator and Your Discriminator are set differently. l Statically configuring a BFD session BFD session parameters, including the local discriminator and the remote discriminator, are configured using commands. Then, a BFD session establishment request is manually distributed. l Dynamically establishing a BFD session When a BFD session is set up dynamically, the system processes the local discriminator and the remote discriminator as follows: Dynamically allocates the local discriminator. When an application triggers dynamic setup of a BFD session, the system allocates a value in the dynamic session discriminator area as the BFD session's local discriminator. Then, the local system sends a BFD control packet with Your Discriminator being 0 to the remote system to negotiate the BFD session. Learns the remote discriminator. When one end of a BFD session receives a BFD control packet with Your Discriminator being 0, the BFD control packet is checked. If the packet matches the local BFD session, this end learns the value of My Discriminator in the packet to obtain the remote discriminator.
Issue 01 (2011-10-30)
523
BFD Session Management

A BFD session has the following states: l l l l Down: indicates that the BFD session is in the Down state or has just been set up. Init: indicates that the local system can communicate with the remote system, and the local system expects a BFD session to go Up. Up: indicates that the BFD session is set up successfully. AdminDown: indicates that the BFD session is in the administratively Down state.
The session status is conveyed in the State field of a BFD control packet. The system changes the session status based on the local session status and the received session status of the peer. When a BFD session is to be set up or deleted, the BFD state machine implements a three-way handshake to ensure that both two systems are aware of the status change. Figure 14-31 shows the state transition process in establishment of a BFD session. Figure 14-31 BFD session state transition
RouterA RouterB
DOWN
Sta: Down Sta: Down
DOWN
DOWN => INIT
Sta: Init Sta: Init
DOWN => INIT
INIT => UP Sta: Up Sta: Up INIT => UP
1.
Router A and Router B enable BFD state machines. The initial status of BFD state machines is Down. Router A and Router B send BFD control packets with the State field being Down. In the static configuration of a BFD session, Your Discriminator in the BFD control packet is specified manually. In dynamic establishment of a BFD session, Your Discriminator is 0. After receiving the BFD packet with the State field being Down, Router B switches the session status to Init and sends the BFD packet with the State field set to Init. After the local BFD session status of Router B changes to Init, Router B no longer processes the received BFD packets with the State field being Down. The BFD session status change on Router A is the same as the BFD session status change on Router B. After receiving the BFD packet with the State field set to Init, Router B changes the local session status to Up.
2. 3. 4. 5.
Issue 01 (2011-10-30)
6.
The BFD session status change on Router A is the same as the BFD session status change on Router B.
14.6.5 BFD for IP

A BFD session is established on an IP link to fast detect faults. BFD can detect single-hop . l Single-hop BFD detects IP route connectivity between directly-connected systems. The single hop refers to an IP hop. Between these two systems, only one BFD session can be set up for a specified data protocol on an interface.
BFD for IP Applications

Figure 14-32 shows a single-hop BFD session detecting a path between directly-connected devices. The BFD session is bound to the outbound interface. Figure 14-32 Single-hop BFD for IP
BFD session 10.1.1.1/25 RouterA BFD session 10.1.1.2/25 RouterB
14.6.6 Application Environment

14.6.6.1 BFD for USR
BFD for Unicast Static Route (USR) is used to detect IPv4 USRs. After a BFD session is bound to an IPv4 USR, link failures can be detected more quickly. Unlike dynamic routing protocols, USRs do not have a detection mechanism. If a fault occurs on a network, an administrator needs to handle it manually. In BFD for USR, BFD sessions are bound to IPv4 USRs in a public network and are used to detect the link status of the IPv4 USR. Each BFD session is bound to a single IPv4 USR. When a BFD session detects a fault (for example, the link changes from Up to Down) on a link of the USR, BFD reports the fault to the routing management module. Then, the RM sets the USR as "inactive" (indicating that the route is unavailable and is deleted from the IP routing table). When the BFD session bound to the USR is successfully set up or the link of the USR recovers from the fault (that is, the link changes from Down to Up), BFD reports the event to the RM and the RM sets the USR as "active" (indicating that the route is available and has been added to the IP routing table).
14.6.6.2 BFD for OSPF

A link fault or change in topology may lead to rerouting in a network. Quick convergence of a routing protocol is important for improving network availability. A feasible solution is to fast detect the fault and immediately notify the routing protocol of the fault. In BFD for OSPF, OSPF is associated with a BFD session. The BFD session fast detects a link fault and notifies OSPF of the fault. In this manner, OSPF speeds up responses to changes in network topology. Table 14-10 shows convergence speed statistics when OSPF is and is not associated with a BFD session. Table 14-10 OSPF convergence speed statistics Associated with BFD No Yes Link Fault Detection Mechanism OSPF Hello keepalive timer timeout BFD session in the Down state Convergence Speed Within seconds Within milliseconds
Figure 14-33 BFD for OSPF networking diagram

RouterC cost1 cost1
RouterA
RouterB
cost1 RouterD
cost10
As shown in Figure 14-33, Router A sets up OSPF neighbor relationships with Router C and Router D. The outbound interface VLANIF 10 on Router A is connected to Router B through Router C. When the neighbor state is Full, BFD is notified of the status and starts to set up a BFD session. 1. 2. When a fault occurs on the link between Router A and Router C, the BFD session detects the fault and notifies Router A. Router A processes the neighbor-Down event and recalculates routes. Then, the outbound interface changes to VLANIF 20 on Router A, which is connected Router B through Router D.
14.6.6.3 BFD for IS-IS

Generally, the interval at which the Intermediate System to Intermediate System (IS-IS) protocol sends Hello messages is 10 seconds. If a device does not receive any Hello message from its
neighbor within three Hello intervals, the device deletes the neighbor. Therefore, it takes a device a number of seconds to detect that a neighbor is Down. This leads to the loss of a large number of packets in a high-speed network. In BFD for IS-IS, the establishment of a BFD session is dynamically triggered by IS-IS but not configured manually. When detecting a fault, the BFD session notifies IS-IS of the fault through the Routing Management Module (RM). IS-IS processes the neighbor-Down event and quickly sends the link state PDU (LSP), and performs the partial route calculation (PRC). In this manner, IS-IS routes fast converge. The BFD fault detection interval is at the millisecond level. Instead of replacing the IS-IS Hello mechanism, BFD works with IS-IS to detect the adjacency fault more quickly. In addition, BFD instructs IS-IS to recalculate routes, ensuring correct packet forwarding. The RM allows IS-IS and BFD to interact with each other. Through the RM, IS-IS instructs BFD to dynamically set up or delete BFD sessions. The BFD event messages are also delivered to ISIS through the RM.
BFD for IS-IS Applications

Figure 14-34 BFD for IS-IS networking diagram
BFD session 10.1.1.1/24 RouterA 10.2.1.1/24 10.1.1.2/24 RouterB BFD session 10.2.1.2/24 RouterC
After BFD is enabled on Router A, Router B, and Router C, the BFD session can quickly detect faults on the link between Router A and Router B, and notify IS-IS through the RM. Then, ISIS sets the neighbor status to Down to trigger the IS-IS topology calculation. In addition, IS-IS updates LSPs to ensure that Router C (Router B's neighbor) can receive the updated LSPs from Router B in time. This implements fast network topology convergence.

Glossary
Table 14-11 Glossary of the terms related to BFD Term Detection mode Description The bidirectional detection mechanism in the BFD protocol is asynchronous.
Issue 01 (2011-10-30)
527
Term Asynchronous mode
Description The BFD control packet is sent periodically between the systems. If the system cannot receive the BFD control packet from the peer end in the detection time, the system disables the session.
Acronyms and abbreviations

Table 14-12 Acronyms and abbreviations related to BFD Acronym/Abbreviation BFD ISIS OSPF VoIP Full Spelling Bidirectional forwarding detection Intermediate System-Intermediate System Open Shortest Path First Voice Over IP
14.7 STM-1 Port Protection Switching

This topic describes the feature of STM-1 port protection switching.
14.7.1 Introduction
Definition
The MA5600T/MA5603T supports TDMoGEM and SAToP (TDM PWE3). The MA5600T/ MA5603T can terminate the TDM service on its STM-1 port to interoperate with other SDH devices. To ensure the reliability of lines, STM-1 port protection is required. The MA5600T/ MA5603T supports board-level protection (1+1 protection) between two boards and port-level protection within a board. With this feature, the MA5600T/MA5603T can automatically cope with network faults.
NOTE
STM-1 port protection is not applicable to a ring network.
Purpose
When a hardware fault or line fault occurs on the STM-1 port under protection, the system immediately switches the service from the faulty port to the backup functional unit.
l l
Issue 01 (2011-10-30)
Switching duration shorter than 50 ms, which is shorter than the duration described in ITUT G.841 1+1 protection, namely, the dual-fed selective receiving mode
l l
Unidirectional protection, without processing the interaction packets of the APS protocol Port-level protection (within-board STM-1 port protection) and board-level protection (cross-board STM-1 port protection), supported by the H801O2CE and H801CSSA daughter boards Port switching triggered in any of the following conditions: A LOS alarm on the active port An SD or SF alarm on the active port Hardware fault on the board where the active port is located Manual configuration of switching (forced switching)

The following lists the reference standard of this feature: l ITU-T G.841
14.7.4 Availability
License Support
STM-1 port protection switching is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service.
Version Support
Hardware Support
l The H801TOPA, H801O2CE, and H802CSSA daughter boards support this feature.
14.7.5 Principle
The fundamental purpose of STM-1 port protection is to quickly switch services to the line of another STM-1 port in case of the failure of one STM-1 port, thus implementing quick switching on the physical plane. If the line status of the working port becomes abnormal, the system should be notified immediately to switch services to the backup member port. Figure 14-35 illustrates the principle of the 1+1 line unidirectional protection of STM-1 ports.
Issue 01 (2011-10-30)
529
Figure 14-35 Principles of the 1+1 line unidirectional protection of STM-1 ports
Work Bridging Normal traffic Selection Protect Bridging Selection Normal traffic
NOTE
In Figure 14-35, C and A respectively represent the two devices connected to the STM-1 ports, Work indicates that the corresponding STM-1 port is the working port, and Protect the protection port.
Figure 14-35 shows that protection switching is performed in one direction. When traffic is transmitted from device C to device A, device C transmits signals to active and standby channels at the same time and device A determines which port is to receive the signals according to the running conditions of the ports. After device A selects the port to receive signals, the port receives signals through a selection switch. Then, the line of the port that receives signals changes to the working state automatically. If the member ports of a protection group are on different boards, the service packets from the UNI side are copied by the LAN switch of the control board and are transmitted to the board where active and standby STM-1 ports are located for processing. In the upstream direction, active and standby STM-1 ports transmit the same traffic. In the downstream direction, the active port is selected to receive traffic and to forward traffic to the UNI side; the traffic received by the standby port is dropped. If the member ports of a protection group are on the same board, the service packets from the UNI side are copied by the logic chip of the daughter board to the transmit direction of the standby STM-1 port; in the downstream direction, the active port is selected to receive traffic and to forward traffic to the UNI side. The system automatically selects active and standby ports according to the physical status and line status of the ports, and does not use the APS protocol to determine protection switching.
14.7.6 Glossary, and Acronyms and Abbreviations

Acronym/Abbreviation TDM APS
Issue 01 (2011-10-30)
Full Spelling Time Division Multiplexing Automatic Protection Switching
530
Acronym/Abbreviation STM-1 SD SF LOS
Full Spelling Synchronous Transport Module Level 1 Signal Degrade Signal Fail Loss Of Signal
14.8 Type C Protection of GPON Lines

This topic describes the type C protection of GPON lines.
14.8.1 Introduction
Definition
The types of the gigabit-capable passive optical network (GPON) line protection group are defined in the ITU-T Recommendation G.984.1. For GPON lines, the Recommendation proposes four protection switching types, among which the type C protection is for both feeder fibers and drop fibers. GPON type C protection is implemented using redundancy configuration of passive optical network (PON) ports on an optical line terminal (OLT), PON ports on an optical network unit (ONU), feeder fibers, optical splitters, and distribution fibers.
Purpose
GPON type C protection ensures higher reliability of devices. The PON ports on an OLT, PON ports on an ONU, feeder fibers, optical splitters, and distribution fibers are in redundancy protection. As such, when any part fails, the system can automatically switch services to the other optical path. The type C protection supports both automatic and manual switching.
Benefits to Carriers
GPON type C protection brings remarkable benefits to carriers. l Ensures higher reliability. When any part on the line fails, the system can automatically detect the fault and switch services to the other optical path, implementing automatic service recovery. Serves as a basic for implementing load balancing in the future, which realizes better bandwidth usage of the lines and at the same time the ONU can provide higher upstream bandwidth.
The maximum number of protection groups is 64. The two members of a protection group can be in the intra-board protection or the inter-board protection.

The reference standards and protocols of the GPON type C protection are as follows: l l l l G.984.1: Gigabit-capable Passive Optical Networks (GPON): General characteristics G.984.3: Gigabit-capable Passive Optical Networks (GPON): Transmission convergence layer specification G.984.4: Gigabit-capable Passive Optical Networks (GPON): ONT management and control interface specification G.841: Types and characteristics of SDH network protection architectures
14.8.4 Availability
Involved NE
This feature requires the OLT to work with the ONU. l l The ONU that is connected to the GPON port in the protect group must provide two PON ports for upstream transmission. The OLT and the ONU must comply with ITU-T G.984.
License Support
The GPON Type C protection is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service.
Version Support
Table 14-14 Version support Product MA5600T/ MA5603T Version V800R010 and later
Feature Dependency
The dependency of the GPON Type C protection is as follows: After an ONU connected to a GPON port is added to a Type C protect group, the GPON port is not allowed to join a Type B protect group, and vice versa.
Hardware Support
l l The boards that support inter-board Type C protection are GPBC and GPBD. The ONU involved must also support the Type C protection.
Issue 01 (2011-10-30)
532

NOTE
l The members of a protect group can be in the inter-board protection. This means that when one member is configured on the GPBC board, the other can be configured on the GPBD board. The features supported by the ONU, however, must be supported by both of the two boards. l A Type C protect group between a GPBD board and a GPBC board is not allowed when traffic streams are already configured on these two boards.
14.8.5 Principle
Single-Homing
Figure 14-36 shows the implementation model. Figure 14-36 GPON type C protection model for single-homing
ONU 1 PON port (1) Optical transceiver+PON MAC 1:N optical splitter OLT PON port (2) Optical transceiver+PON MAC
PON port (1)
PON port (2)
1:N optical splitter
ONU N PON port (1) Optical transceiver+PON MAC PON port (2) Optical transceiver+PON MAC
Dual PON ports on an OLT can be configured using either of the following methods: 1. 2. Configure intra-PON board PON MAC chip protection. Configure inter-PON board PON port protection.
The following section describes the working status of each device in a protection switchover. l OLT: Both the active and standby PON ports are in the working state. The OLT must ensure that the service data on the active PON port can be backed up to the standby PON port simultaneously. In such a manner, the standby PON port can maintain the same service attributes of the ONU in a protection switchover. Optical splitter: Two 1:N optical splitters are used. ONU: uses different PON MAC chips and optical modules. The ONU must ensure that the service data on the active PON port is the same as that on the standby PON port. In such a manner, the ONU can maintain the local service attributes in a PON port protection switchover.
l l
Issue 01 (2011-10-30)
The switchover principle is as follows: l The active and standby PON ports on the OLT must be in the working state. That is, the ONU completes the physical layer OAM (PLOAM) registration and processes standard and extended optical network terminal management and control interface (OMCI) messages on the two PON ports. OAM is the abbreviation for operation, administration, and maintenance. In a PON port protection switchover, initialization parameters and service attributes of the ONU are not configured on the standby PON port. Both the ONU and the OLT check the link status and determine whether to perform a switchover based on the link status. When detecting that the uplink of the active PON port is faulty, the OLT automatically switches services to the standby optical link. In addition, the OLT sends PST messages over the standby optical link to the ONU and requests the ONU for a switchover. When detecting that the downlink of the active PON port is faulty, the ONU automatically switches services to the standby optical link. In addition, the ONU sends PST messages to inform the OLT of the switching and the reason for the switching, requesting the OLT for a switchover. G.984.1 specifies two types of conditions for triggering a protection switchover: 1. 2. Forcible switchover Automatic switchover
The conditions triggering an automatic switchover include a quality degradation alarm on an uplink or downlink, a hardware fault, or loss of frame (LOF), signal fail (SF), signal degrade (SD), or LCDG alarm on an ONU. The protection group supports automatic recovery and automatic recovery hold time. Automatic recovery means that the system automatically switches services back to the link connected to the original working member after its link recovers from a fault.
14.9 GPON Port 1+1 Backup

This topic describes the introduction, principle, and reference documents of the feature GPON port 1+1 backup.
14.9.1 Introduction
Definition
GPON port 1+1 backup is a Type B port protection solution defined in the GPON 984.1 protocol, providing redundancy protection to ports and optical fibers.
Purpose
GPON port 1+1 backup provides redundancy protection for ports and optical fibers. This ensures high reliability of the device.
The MA5600T/MA5603T supports the following specifications of GPON port 1+1 backup.
l l l l l
Backup for two ports on one board or on two boards MA5600T: Up to 64 port protect groups for each subrack MA5603T: Up to 24 port protect groups for each subrack Manual switchover or automatic switchover is supported. The service interruption time during switchover is less than 300 ms. Triggering an automatic switchover: hardware failures, fractures of optical fibers, quality deterioration of lines or hot swapping of the active control board. The switchover of xPON ports in the 1+1 protection group triggered by the LOS alarm due to fiber disconnection is supported. The switchover of xPON ports in the 1+1 protection group triggered by the alarm generated when the upstream bit error ratio on the port exceeds the threshold is supported. The switchover of xPON ports in the 1+1 protection group triggered by the alarm generated when the downstream bit error ratio on the port exceeds the threshold is supported.

The following lists the reference document of this feature: l ITU-T G.984.1-G.984.1
14.9.4 Availability
Availability
l l Hardware Support All GPON access boards support this feature. License Support GPON port 1+1 backup is a basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Other
The boards that provide the ports in one protect group must be of the same type, because different boards may support different features.
14.9.5 Principle
The ITU-T G.984.1 defines four types of protection switching from Type A to Type D. This topic describes the principle of Type B protection switching. Figure 14-37 shows the network of GPON Type B protection. Type B protection protects the active and standby PON ports on the OLT and the active and standby optical fibers between the OLT and the optical splitter.
Issue 01 (2011-10-30)
535
Figure 14-37 GPON Type B protection defined in the ITU-T G.984.1
Protection range ONU 1
Active PON port
Optical splitter
Standby PON port
OLT
ONU N PON port
When the active PON port works in the normal state, the standby PON port receives optical signals going upstream from the ONU. When no signals are transmitted upstream because the optical fiber connected to the active PON port is cut or the GMAC chip works abnormally, the standby PON port detects the optical signal interruption and performs associated processing immediately. The following describes the protection switching in two different scenarios. l Scenario 1: The active optical fiber is cut when the active PON port is working, as shown in Figure 14-38. Figure 14-38 Active optical fiber cut
ONU 1
Protection range
Active PON port
Optical splitter
Standby PON port
OLT
ONU N PON port
After entering the standby state, the standby PON port enables detection of upstream optical signals. When detecting a loss of signal (LOS) alarm (generated due to the active optical fiber cut), the active PON port disables the transmission of its optical module. After detecting the LOS alarm of the active PON port, the standby PON port enables the transmission of its optical module and performs the ONU detection.
When the optical fiber connected to the standby PON port is in the normal state and ONUs are discovered, the standby PON port reports an LOS clear alarm. The active PON port switches to the standby state and enables detection of upstream optical signals. The standby PON port switches to the active state. Till now, the protection switching is completed. l Scenario 2: All ONUs connected to the active PON port go offline, as shown in Figure 14-39. Figure 14-39 All ONUs going offline
ONU 1
Protection range
Active PON port
Optical splitter
Standby PON port
OLT
ONU N PON port
After entering the standby state, the standby PON port enables detection of upstream optical signals. When detecting an LOS alarm (generated because all ONUs go offline), the active PON port disables the transmission of its optical module. After detecting the LOS alarm of the active PON port, the standby PON port enables the transmission of its optical module and performs the ONU detection. The OLT keeps checking for ONUs on the active and standby PON ports until it detects an ONU going online. After the ONU goes online, no switching is performed between the PON ports.
Issue 01 (2011-10-30)
537
15 Voice Feature
15
About This Chapter
15.1 Introduction 15.2 Specifications 15.3 Availability 15.4 ISDN
Voice Feature
This topic describes the features in relation to the voice service.
15.5 MGCP Voice Services This topic describes the MGCP protocol and the working principle of MGCP application in VoIP, MoIP and FoIP. 15.6 H.248 Voice Services This topic first describes the H.248 protocol, and then describes the protocol mechanism, and last describes the application of H.248 in VoIP, MoIP, and FoIP. 15.7 SIP Voice Services This topic first describes the SIP protocol, and then describes in detail the principle of the SIP protocol. 15.8 Key Voice Feature This topic provides the overview of key voice features and then describes working principle of each sub feature in detail. 15.9 Voice Interface Feature This topic describes the features in relation to the voice interface, including basic features such as ringing and Z interface and enhanced features. 15.10 Voice Test and Maintenance The test and maintenance features of voice services include the loop line test, circuit test, call emulation test, continuity test, and Real-time Transport Control Protocol (RTCP) statistics. 15.11 Voice Reliability This topic describes features related to voice reliability, including dual-homing networking, highly reliable transmission (SCTP), and voice QoS.
15 Voice Feature
15.1 Introduction
The MA5600T/MA5603T not only provides broadband services (including data and video live/ on demand service), but also provides high-quality voice services by the built-in voice module for the end users directly over twisted pairs. Such MA5600T/MA5603Ts fit in with the trend of data, voice, and video services integration. Figure 15-1 illustrates the overall voice service solution of the MA5600T/MA5603T. Figure 15-1 Overall voice service solution
Service board POTS interface SLIC CODEC . . . . . . POTS interface SLIC CODEC TDM bus CPU DSP subboard Control board
TDM bus
Switching module
Interface module
Service board
VoIP service channel Signaling channel
In this figure, SLIC is the short form for subscriber line interface circuit. It is used for processing analog signals. It sends the feed and voice frequency to the telephone for generating the ring tone and signals such as the offhook detection signal and onhook detection signal. CODEC is used for converting between analog signals and digital signals. DSP is used for processing voice frequency (such as voice encoding, echo cancellation, and DTMF generation and detection), and converting digital signals into VoIP packets. The VoIP service channel and signaling channel are indicated by the dotted lines in different colors in Figure 15-1.
15.2 Specifications
l l Supporting the H.248, MGCP, and SIP voice protocols Supporting VoIP, FoIP, and MoIP (Table 15-1 lists the specific services supported) Table 15-1 Voice services supported Type Basic SIP call services
Issue 01 (2011-10-30)
Service SIP service

539
15 Voice Feature
Type
Service SIP call holding service SIP three-party service SIP call waiting service SIP conference calling service SIP call transfer service SIP registration and management SIP fax service SIP modem service SIP calling line identification presentation (CLIP) service Notification and display of the charge information of SIP calls (advice of charge at the end of the call only) SIP message waiting indicator (MWI) service SIP malicious call tracing SIP UA (User Agent) profile subscription Charging service Distinctive ringing Common POTS service New POTS services: l Calling party release l Called party release l Last-party release l First-party release l Call waiting service l Call transfer service l Call forwarding service l Co-group pickup service l Designated pickup service l Three-party service l Conference calling service l CLIP service
MGCP/H.248 services
Issue 01 (2011-10-30)
540
15 Voice Feature
Type
Service FoIP services: l Auto-switching fax service l T.30 transparent transmission fax service l T.38 fax service l Configuring of fax parameters, and V2 and V3 fax flows MoIP services: l Transparent transmission modem service l Auto-switching modem flow l Softswitch-controlled modem flow l Delay mode of event reporting l Direct mode of event reporting l Low-speed modem l High-speed modem ## service Charging service MWI service Distinctive ringing Advice of charge at the end of conversation Dual tone multi-frequency (DTMF) transmission
l l l
Supporting the G.711A/Mu encoding/decoding at the packetization periods of 10 ms, 20 ms, 30 ms, 40 ms, 50 ms, 60 ms Supporting the G.729 encoding/decoding at the packetization periods of 10 ms, 20 ms, 30 ms, 40 ms, 50 ms, 60 ms Supporting the RFC2833 encryption(only H.248 and MGCP) and RFC2198 and voice features such as echo cancellation (EC), voice activity detection (VAD), DTMF, voice quality enhancement (VQE), and modem quality enhancement Supporting circuit test, loop line test, call emulation test, and connectivity test Supporting H.248, MGCP, and SIP dual homing Supporting the digitmap with a length of 8 K bytes Supporting 32 or 64 G.711 DSP channels, or 32 G.729 DSP channels Supports virtual access gateway (VAG). When the system protocol is MGCP, a maximum of eight MG interfaces with different indexes can be configured on the MA5600T/MA5603T, and each MG interface can be considered a VAG.
l l l l l
Issue 01 (2011-10-30)
541
15 Voice Feature
When the system protocol is H.248, a maximum of eight MG interfaces with different indexes can be configured on the MA5600T/MA5603T, and each MG interface can be considered a VAG. When the system protocol is SIP, a maximum of eight SIP interfaces with different indexes can be configured on the MA5600T/MA5603T, and each SIP interface can be considered a virtual SIP AG.
NOTE
l A physical access gateway (AG) can be logically divided into multiple VAGs, and each VAG is able to work independently under the control of a core network device (softswitch or IMS). In this way, an AG is able to provide access services for multiple VAG users. l When Stream Control Transmission Protocol (SCTP) is used as the transport layer protocol, H.248 and SIP each support only one VAG.
Support Emergency Standalone (H.248 and SIP)
15.3 Availability
In terms of software, the software for voice features is included in the basic software package. In terms of hardware, the voice service boards and the DSP daughter board need to be configured, and an upstream port on the SCU control board or GIU board must be used for upstream transmission of the voice service.
Related Network Elements

Devices on the core network such as NGN and IMS devices are required to work with the MA5600T/MA5603T for implementing the voice feature.
License Support
The voice feature is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service.
Version Support
Hardware Support
l The DSRD board support ISDN, the ASPB and CAME boards support POTS.
15.4 ISDN
The integrated services digital network (ISDN) is a CCITT standard, providing integrated transmission service for voice, video, and data. The ISDN enables the voice, video, and data to be transmitted on the data channel simultaneously.
15 Voice Feature
15.4.1 Introduction
Definition
The integrated services digital network (ISDN) is a CCITT standard, providing integrated transmission service for voice, video, and data. The ISDN enables the voice, video, and data to be transmitted on the data channel simultaneously. The ISDN supports two types of services: l l Basic rate interface (BRI): provides the rate of 144 kbit/s, including two B channels and one D channel. Primary rate interface (PRI): provides the rates of 2.048 Mbit/s, including 30 B channels and one D channel.
The B channel is used to bear services, and the D channel is used to transmit the call control signaling and maintenance management signaling.
Purpose
The ISDN access on the media gateway provides integrated transmission services, such as voice, video, and data for the users.
Specifications
l l l l The BRA provides two B channels and one D channel, and the rates of the B channel and D channel are 64 kbit/s and 16 kbit/s respectively. The PRA provides 30 B channels and one D channel, and the rate of the channels is 64 kbit/ s. The optimized TID strategy is supported. The TID implementation is the same as that of the PSTN. The H.248 upstream and MGCP upstream modes are supported.
Glossary
Table 15-3 Glossary related to the ISDN Glossary BRA Explanation The ISDN subscribers access the media gateway through the BRI by the H.248 protocol or MGCP. The BRI provides two B channels and one D channel, with rates of 64 kbit/s and 16 kbit/s respectively. Terminal adapter. It is used to adapt the non-ISDN terminals and enable the common telephone to access the ISDN. ISDN compatible terminal. It is used to enable the digital terminal usage in the ISDN directly. ISDN incompatible terminal, that is, the non-ISDN digital terminal. For example, the common PSTN telephone and facsimile apparatus, which can be used in the ISDN through being adapted with the TA.
TA TE1 TE2
Issue 01 (2011-10-30)
15 Voice Feature
Glossary NT1
Explanation The NT1 provides the U interface and S/T interface, connecting the ISDN terminal and ISDN switch. The NT1 enables the code conversion between the U interface and the S/T interface, for example, the standard Chinese 2B1Q/AMI code conversion. Generally, the NT1 is oriented to the devices in the pure physical layer, without software intelligence. The NT1 can maintain the line and monitor the performance to ensure the clock synchronization of the ISDN terminal and network. Intelligent terminal device. The common NT2 device includes the terminal control devices of the ISDN functions, such as the mini-switch PABX and LAN router. The ISDN users access the media gateway through the PRI by the H.248 protocol or MGCP. The PRI provides one D channel and 30 B channels, with the rate of 64 kbit/s.
NT2
PRA

Table 15-4 Acronyms and abbreviations related to ISDN Acronym/Abbreviation BRA BRI PRA PRI IUA TA TEI NT1 NT2 Full Name Basic Rate Access Basic Rate Interface Primary Rate Adaptation Primary Rate Interface ISDN Q.921-User Adaptation Layer Terminal Adapter Terminal Equipment Identifier Network Terminal Type 1 Network Terminal Type 2

This topic provides the reference documents of the ISDN: l l l l
Issue 01 (2011-10-30)
ITU-T Q.920 ISDN user-network interface data link layer General aspects ITU-T Q.921 ISDN user-network interface - Data link layer specification ITU-T Q.930 Digital Subscriber Signalling System No.1 (DSS 1) -ISDN User-Network Interface Layer 3 - General Aspects ITU-T Q.931 ISDN user-network interface layer 3specification for basic call control
15 Voice Feature
l l l l l
ITU-T H.248 Media gateway overload control package RFC3435 Media Gateway Control Protocol (MGCP) Version 1_0 RFC3660 Basic Media Gateway Control Protocol (MGCP) Packages RFC3661 Media Gateway Control Protocol (MGCP) Return Code Usage ITU-T G.961 Digital transmission system on metallic local lines for ISDN basic rate access
15.4.3 Basic principles

ISDN Reference Model
Figure 15-2 shows the ISDN reference model. Figure 15-2 ISDN reference model
S TE1 NT2 T NT1 U MG MGC or LE
R TA
S Reference point Function group
The ISDN users access the MA5600T/MA5603T through the reference point U, and the actual terminal device on the user side may process the NT1, NT2, and TE1 functions simultaneously. For the VoIP upstream, use the IUA protocol to bear the Q.931 call signaling of the ISDN between the MG and MGC, and use the H.248 protocol or MGCP signaling to control the media connection on the MG.
ISDN System Structure

Figure 15-3 shows the ISDN system structure.
Issue 01 (2011-10-30)
545
15 Voice Feature
Figure 15-3 ISDN System Structure
The ISDN users include the BRA users and PRA users. l The BRA users can connect the ISDN telephone with the NT1 directly, or connect the common telephone through the TA. On the MG side, the BRA users access to the network through the BRA port. Connect the NT1 and MG with the ordinary telephone line. The PRA users access the network through the E1 port with the PBX. Connect the PBX and the gateway with the E1 cable.
ISDN Call Control Process

The ISDN uses the Q931 protocol to control the call. Set up a Layer 2 link between the gateway and NT1 and the PBX to bear the Q931 information. The link must comply with the Q921 protocol. Set up an IUA link to bear the Q931 information between the gateway and softswitch. Figure 15-4 shows the ISDN call control process.
Issue 01 (2011-10-30)
546
15 Voice Feature
Figure 15-4 ISDN call control process
In the primitive Q931, the gateway does not include in the call control. The gateway takes out the primitive terminal Q931 from the Q921 information packet, encapsulates the Q.931 to the IUA information packet, and then sends to the softswitch. The call process includes two sections: call setup and call disconnection. l The call setup process is as follows: 1. 2. 3. 4. 5. 6. 7. 8. l 1. 2. 3. The host hooks off and initiates a call setup. The softswitch responds "SETUP_ACK", and applies more call information, such as the called number. The calling party dials, and the number is carried by the primitive IMFORMATION to the softswitch. The softswitch responds "CALL PROCEEDING", and the call is setting up. The softswitch applies sending setup to the called party to set up a call. After receiving the call, the called party starts ringing and sends "ALERTING". If the "ALERTING" reaches the calling party, the call is connected. The called party hooks off and sends "CONNECT". If the "CONNECT" reaches, the call is connected. The calling party responds "CONNECT_ACK". The call setup is complete. One party hooks on, and sends "DISCONNECT". The softswitch sends "DISCONNECT" to the other party, and sends "RELEASE" to the party who hooks on. The party who hooks on finishes the call disconnection, and sends "RELEASE_COMPLETE" to the softswitch.
The call disconnection process is as follows:
Issue 01 (2011-10-30)
15 Voice Feature
4. 5. 6.
After receiving the disconnection, the other party sends "RELEASE" to the softswitch. The softswitch responds "RELEASE_COMPLETE". The other party hooks on, and sends "DISCONNECT". The call disconnection is complete.
15.4.4 The Principles of ISDN BRA

Figure 15-5 shows the principles of the ISDN BRA. Figure 15-5 Principles of the ISDN BRA
User Access
Entering the AN from the MG side, the BRA user call from the deactivated state experiences four stages: activation, TEI application, Layer 2 link setup, and Layer 3 call control. If the port terminal is activated, the TEI is distributed, or the Layer 2 link is set up, skip to next stage.
Call Control
According to the signaling round-trip control, the call signaling on the MG is sent to the softswitch through the IUA (as the red line in the figure). The softswitch delivers the media control information through the H.248 protocol/MGCP protocol, and controls the resources on the MG (as the blue line in the figure), such as the B channel, context (H.248), and terminal. Create an IUA service environment on the MG and MGC sides. Bear the Q.931 signaling on the DSL board to the SCTP link, pack the signaling through the IUA protocol stack, and then send the packet to the MGC. Switch the Q.931 signaling on the MGC side. The MGC sends the Q. 931 signaling to the peer end through the SCTP link to perform ISDN signaling call.
15 Voice Feature
Working Mode
The BRA working modes include point to multipoint (P2MP) and point to point (P2P). l In the P2MP mode, one NT1 can connect to multiple terminals. Multiple Layer 2 links can be created at the same time, and up to two users can call simultaneously. If no call service exists, the system can be deactivated automatically to save the power. In the P2P mode, one NT1 can connect to one terminal only. The Layer 2 link is always set up to ensure the service bearing at any moment. No matter whether the call service exists, the link is activated.
Terminal Power Supply Mode

The BRA power supply is to provide power for the terminal. Two terminal power supply modes are provided: l l Local power supply: The terminal applies battery or connects to the power supply. NT1 power supply: The terminal uses the NT1 power supply only. The NT1 power supply falls into two categories: Local power supply: The NT1 connects to the local power supply. Gateway power supply: Configure the remote power supply attribute of the BRA port on the gateway.
Terminal Identifier Distribution

In the P2MP mode, if the physical line of the BRA user is activated, one BRA port can connect multiple terminals. A terminal equipment identifier (TEI) is needed to identify the terminal. The TEI can be specified by the terminal, or distributed on the network side. l l l The TEI that the terminal specifies ranges 0-63. The TEI on the network side is distributed by the subscriber board, ranging 64-126. The 127, as a multicast TEI, is used when the BRA user is called (all the users under the same port share the same telephone number). When the destination terminal is unknown, the connections to all the terminals are initiated. In the P2P mode, the terminal TER is 0.
15.5 MGCP Voice Services

This topic describes the MGCP protocol and the working principle of MGCP application in VoIP, MoIP and FoIP.
15.5.1 Introduction
Definition
Defined by IETF, MGCP is a protocol that specifies a call control mechanism in which call control and service bearing are separated. Call control is independent of the media gateway (MG) and is processed by the MGC. Therefore, MGCP is actually a master-slave protocol. The MG establishes various service connections under the control of the MGC. MGCP provides the following commands:
15 Voice Feature
1.
NotificationRequest: The MGC sends this command to request the MG to detect a specified event, such as an offhook event or onhook event. After detecting such an event, the MG notifies the MGC. Through this command, the MGC can also instruct the MG to play signal tones, such as the dial tone and busy tone. Notify: After the MG detects the specified event as instructed by the MGC, the MG sends this command to notify the MGC of the detected event. CreateConnection: The MGC sends this command to instruct the MG to create a media connection. The command contains the instruction or suggestion on the bearing parameters and connection parameters. ModifyConnection: The MGC sends this command to instruct the MG to modify the bearing parameters and connection parameters of an established media connection. DeleteConnection: The MGC sends this command to instruct the MG to delete an established media connection. The MG can also voluntarily delete a connection. This means that, when the MG discovers that system resources are insufficient or the system is faulty, the MG can delete the connection and at the same time send this command to notify the MGC. Therefore, this command is bi-directionally available between the MGC and the MG. AuditEndpoint and AuditConnection: The MGC sends the commands to check the status of a specified endpoint and connection. RestartInProgress: The MG sends this command to notify the MGC that the MG or a certain endpoint managed by the MG is not available or is becoming available. This command is usually triggered by a system fault or restart.
2. 3.
4. 5.
6. 7.
MGCP also provides the following features: 1. 2. 3. 4. Encoding in the text format Adopting the Session Description Protocol (SDP) to describe the connection parameters of the media stream Introducing the concept of event package Adopting the wildcard to describe endpoints and events
Purpose
MGCP solves the internal problems of MG and media devices, thus realizing an open distributed system which is formed by the MG and media devices. In the MGCP mechanism, the MG and media devices are separated into two logically independent parties, the MG and the MGC, which communicate through MGCP. The MG processes the user plane, and the MGC processes the control plane and controls the actions of the MG. In other words, the MG acts under the control of the MGC.

l l l RFC2705 RFC3405 T.30: It is based on the PSTN network. T.30 particularly defines the flow for transmitting fax signals on the PSTN network. It also defines the modulation mode (V.17/V.21/V.27/ V.29/V.34) and transmission format (HDLC) of data, and the physical standard for fax signals. The T.30 fax messages and data can be transmitted transparently between MGs.
Issue 01 (2011-10-30)
15 Voice Feature
This is called the T.30 transparent transmission mode. The quality of the fax in this mode may not be high due to packet loss, latency, and disorder on the IP network. l T.38: It is a real-time fax mode based on the IP network. In this mode, the MG terminates the T.30 signals sent from the fax machine, and transmits the data to the peer MG in the T. 38 mode. The peer MG then receives the T.38 packets and converts the packets into T.30 signals. The merit of the T.38 fax is that the fax packets have a redundancy processing mechanism and do not strictly rely on the quality of the network (the fax service can be processed even when a 20% packet loss occurs on the network). The demerit is that the DSP chip needs to participate in parsing the T.30 signals. Because there are various types of terminals on the network, the compatibility problem may arise.
15.5.3 Principle
15.5.3.1 MGCP-Based VoIP
Figure 15-6 illustrates the principle of the call establishment and release in the MGCP-based VoIP service. Figure 15-6 Principles of the call establishment and release in the MGCP-based VoIP service
Figure 15-7 illustrates the basic flow of a call establishment and release process.
Issue 01 (2011-10-30)
551
15 Voice Feature
Figure 15-7 MGCP-based call flow
1. 2.
AG-0 detects the offhook of EP0, and notifies the MGC of the offhook event through the Notify command. After the MGC receives the offhook event, the MGC sends a digitmap to AG-0, requests AG-0 to play the dial tone to EP0, and at the same time checks for the digit collection event.
Issue 01 (2011-10-30)
552
15 Voice Feature
3. 4. 5.
User EP0 dials a telephone number, and AG-0 collects the digits according to the digitmap issued by the MGC. Then, AG-0 reports the result of digit collection to the MGC. The MGC sends the CRCX (CreateConnection) command to AG-0 requesting AG-0 to create a connection at endpoint EP0. AG-0 allocates resources for creating this connection and sends a response to the MGC. The response contains the session description that provides the necessary information for the peer end to send the packet to AG-0, such as the IP address and UDP port number. The MGC sends the CRCX command to AG-1 requesting AG-1 to create a connection at endpoint EP1. AG-1 allocates resources for creating this connection and sends a response to the MGC. The response contains the session description that provides the necessary information for the peer end to send the packet to AG-1, such as the IP address and UDP port number. AG-1 detects the offhook of EP1, and sends the Notify command to the MGC. The softswitch (MGC) sends the MDCX (ModifyConnection) command to stop the ring back tone of EP0 and the ringing of EP1. The MGC sends the session description of AG-1 to EP0 through the MDCX command. Then, the conversation is set up between EP0 and EP1.
6. 7.
8.
9.
10. AG-0 detects the onhook of EP0, and notifies the MGC of the onhook event through the Notify command. 11. The MGC sends the MDCX command to AG-0 and AG-1 respectively to modify the RTP resource to receive-only. 12. The MGC sends the MDCX command to AG-1 requesting AG-1 to play the busy tone to EP1, and at the same time checks for the onhook event. 13. The MGC sends the DCLX (DeleteConnection) command to AG-0, requesting AG-0 to release the resources that are occupied by the call of EP0. 14. AG-1 detects the onhook of EP1, and notifies the MGC of the onhook event through the Notify command. 15. The MGC sends the DCLX command to AG-1, requesting AG-1 to release the resources that are occupied by the call of EP1. 16. The call between EP0 and EP1 is terminated, and all the resources occupied by the call are released.
15.5.3.2 MGCP-Based MoIP

MoIP refers to the modem service provided on the IP network or between the IP network and the traditional PSTN network. According to different control devices, MoIP can be classified as softswitch-controlled MoIP and auto-switching MoIP.
Softswitch-Controlled MoIP
The basic flow of the softswitch-controlled MoIP service is as follows: 1. 2. 3. Establish a call. If the MoIP service is configured on the softswitch, the softswitch sends a command to the MG instructing the MG to detect the modem event. The calling party and called party start communicating with each other. During the call, when the MG detects the ANS or ANSAM modem start event (low-speed modem signal), or detects the ANSBAR or ANSAMBAR modem start event (high-speed modem signal), the MG sends the event to the softswitch.
Issue 01 (2011-10-30)
15 Voice Feature
4. 5.
According to the event, the softswitch sends a command instructing the MG to switch the DSP channel of the calling and called parties to the low-speed or high-speed modem mode. According to the command sent by the softswitch, the MG switches the DSP channel to the corresponding modem mode. At this stage, the MG adopts the encoding format and port number specified by the softswitch. The settings of echo cancellation (EC), voice activity detection (VAD), and DSP working mode are as follows: (1) Low-speed modem: EC-ON, VAD-OFF, DSP working mode-modem mode (2) High-speed modem: EC-OFF, VAD-OFF, DSP working mode-modem mode
6.
7.
After the modem data is transmitted, if the conversation proceeds, the DSP working mode does not automatically switch from the modem mode to the voice mode, because the modem end event is not issued. As a result, the quality of the voice service may be affected.
Auto-Switching MoIP
The basic flow of the auto-switching MoIP service is as follows: 1. 2. Set up a conversation. The MGs at both ends check for the modem event on the IP side and the TDM side. When the modem event is detected, if the modem transmission mode is configured as autoswitching, the coding mode is switched to G.711 (the a/ law is configurable), and the DSP parameters are modified according to the modem mode (high-speed/low-speed) detected. When the modem service is terminated, the call is released.
3.
15.5.3.3 MGCP-Based FoIP

FoIP refers to the fax service provided on the IP network or between the IP network and the traditional PSTN network. The fax machine can be regarded as a special modem. In the FoIP negotiation, the modem negotiation is performed before the fax negotiation. According to the transmission protocol adopted, there are two modes of fax services carried on the IP network: the T.30 transparent transmission mode and the T.38 mode. According to different control devices, FoIP can be classified as softswitch-controlled FoIP and autoswitching FoIP.
Softswitch-Controlled FoIP
The fax service can be classified into high-speed fax and low-speed fax. The softswitchcontrolled low-speed fax service supports the T.30 transparent transmission mode and the T.38 mode. The basic service flow is as follows: 1. 2. 3. 4. 5.
Issue 01 (2011-10-30)
Configure the fax service and fax flow on the MGs and the softswitch. After the voice channel is set up, the softswitch instructs the MG to detect the fax event and modem event. When detecting the fax event, the MG reports the event to the softswitch. The event can be a low-speed modem event (ANS or ANSAM) or a low-speed fax event (V.21Flag). According to the preset fax flow, the softswitch instructs the MGs at both ends to change the DSP channel working mode to the T.30 transparent transmission mode or T.38 mode. The fax starts.
15 Voice Feature
6. 7. 8.
After the fax is complete, if the MG detects the fax end event, the MG reports the event to the softswitch. The softswitch instructs the MGs at both ends to change the DSP channel working mode to the voice mode. The voice service proceeds.
The softswitch-controlled high-speed fax service supports the T.30 transparent transmission mode. The basic service flow is as follows: 1. 2. 3. Configure the fax service and fax flow on the MGs and the softswitch. After the voice channel is set up, the softswitch instructs the MG to detect the fax event and modem event. When detecting a fax event, the MG reports the event to the softswitch. The event can be a high-speed modem event (ANSBAR or ANSAMBAR) or a low-speed fax event (V. 21Flag; if the peer end is a low-speed fax machine or the network quality is poor, the fax speed is automatically decreased and this event is reported). According to the preset fax flow, the softswitch instructs the MGs at both ends to change the DSP channel working mode to T.30 transparent transmission mode. The fax starts. After the fax is complete, if the MG detects the fax end event, the MG reports the event to the softswitch. The softswitch instructs the MGs at both ends to change the DSP channel working mode to the voice mode. The voice service proceeds.
4. 5. 6. 7.
Auto-Switching FoIP
The auto-switching fax service supports the T.30 transparent transmission mode and the T.38 mode. The basic service flow is as follows: 1. 2. 3. Configure the auto-switching fax service on the MGs at both ends. Establish a call and use the voice service. The MG checks for the fax event on the IP side and the TDM side. When detecting the fax event, the MG changes the DSP channel working mode to the T.30 transparent transmission mode or the T.38 mode. After the fax is complete, when the MG detects the fax end event, the MG changes the DSP channel working mode to the voice mode. The voice service proceeds.
4. 5.
Common Fax Protocols

Two protocols are usually used for implementing the fax service on the packet voice network: the ITU-T Recommendation T.30 and ITU-T Recommendation T.38. T.30 is based on the PSTN network. T.30 particularly defines the flow for transmitting fax signals on the PSTN network. It also defines the modulation mode (V.17/V.21/V.27/V.29/V.34) and transmission format (HDLC) of data, and the physical standard for fax signals. The T.30 fax messages and data can be transmitted transparently between MGs. This is called the T.30 transparent transmission mode. The quality of the fax in this mode may not be high due to packet loss, latency, and disorder on the IP network. T.38 is a real-time fax mode based on the IP network. In this mode, the MG terminates the T. 30 signals sent from the fax machine, and transmits the data to the peer MG in the T.38 mode.
15 Voice Feature
The peer MG then receives the T.38 packets and converts the packets into T.30 signals. The merit of the T.38 fax is that the fax packets have a redundancy processing mechanism and do not strictly rely on the quality of the network (the fax service can be processed even when a 20% packet loss occurs on the network). The demerit is that the DSP chip needs to participate in parsing the T.30 signals. Because there are various types of terminals on the network, the compatibility problem may arise.Figure 15-8 illustrates the principle of the T.38 fax. Figure 15-8 Principle of the T.38 fax
15.6 H.248 Voice Services

This topic first describes the H.248 protocol, and then describes the protocol mechanism, and last describes the application of H.248 in VoIP, MoIP, and FoIP.
15.6.1 Introduction
Definition
H.248 is a media gateway control protocol through which the media gateway controller (MGC) controls the media gateway (MG) so that interoperability is implemented between different media. ITU-T issued the first version of this protocol in June 2000.
Purpose
Compared with MGCP, H.248 has the following merits:
15 Voice Feature
l l l
Supports more types of access technologies, and is more thorough and complete in standardization Compensates for the deficiency of MGCP in descriptiveness, is applicable to larger networks and has better extensibility and flexibility Carried on various protocols, such as UDP/SCTP (MGCP is carried on UDP)

l RFC3525 H.248 Protocol
15.6.3 Working Principle

15.6.3.1 Mechanism of the H.248 Protocol Termination ID
A termination ID identifies a termination that is going to register or deregister a service. The termination ID of each termination is unique. During service configuration, the termination ID corresponding to each termination must be configured on the MG and the MGC. The root termination ID represents an entire MG. The ServiceChange command executed on the root termination ID is effective on an entire MG. The wildcarding principle is that the ALL wildcard (*) can be used but the CHOOSE wildcard ($) cannot be used.
Registration Mechanism of the H.248 Interface

The MG sends the ServiceChangeRequest command to inform the MGC that a user or a group of users are about to register or deregister service. After this command is executed successfully, the termination status is changed to InService or OutOfService. In addition, the MGC can unsolicitedly send the ServiceChangeRequest command to request the MG to register or deregister service for a user or a group of users.
NOTE
Currently, the MG does not support the MGC to unsolicitedly send the ServiceChangeRequest command requesting the MG to register service for a user or a group of users.
Figure 15-9 shows the registration flow of the MG.
Issue 01 (2011-10-30)
557
15 Voice Feature
Figure 15-9 Registration flow of the MG
Description of the flow: 1. The MG sends the ServiceChangeRequest command to the MGC. In the command, TerminationId is Root, Method is Restart, and ServiceChangeReason is 901 (cold boot, registering for the first time after power-on), 902 (warm boot, through command lines), or 900 (in other cases). The MGC sends the Reply message to the MG indicating the successful registration. The MGC sends the Modify command to the MG requesting the MG to detect the offhook of all users (al/of). The MG responds to the MGC with the Reply message.
2. 3. 4.
Heartbeat Mechanism of the H.248 Interface

After the registration is successful, the MG and the MGC maintain communication by sending each other the heartbeat message Notify (it/ito). By default, the heartbeat message is sent every 60s. The sending interval can be set within the range of 5-655s. After the MG sends the first heartbeat message to the MGC, if the MG does not receive the heartbeat response from the MGC before the preset interface heartbeat timer (for example, the length of three sending intervals) times out, the MG sets the interface status to "wait for response". Then, the MG keeps initiating a registration with the MGC. If dual-homing is configured, the MG initiates registration with the two MGCs alternatively. The registration is initiated once every 30s, every three trials of registration are one round, and every registration message is re-transmitted 7 times. Therefore, 24 registration messages in total are transmitted within 90s. Then, the MG starts the next round of registration with the other MGC.
Deregistration Mechanism of the H.248 Interface

Figure 15-10 shows the unsolicited deregistration flow of the MG.
Issue 01 (2011-10-30)
558
15 Voice Feature
Figure 15-10 Unsolicited deregistration flow of the MG
Description of the flow: 1. The MG sends the ServiceChangeRequest command to the MGC. In the command, TerminationId is Root, Method is Forced, and ServiceChangeReason is 905 ("905" indicates that the termination is taken out of service because of maintenance operation, and now the MG uses "905" to initiate a deregistration request through command lines). The MGC sends the Reply message to the MG indicating a successful deregistration.
2.
Figure 15-11 shows the flow of the MGC unsolicitedly deregistering the MG.
Figure 15-11 Unsolicited deregistration flow of the MGC
Description of the flow: 1. The MGC sends the ServiceChangeRequest command to the MG. In the command, TerminationId is Root, Method is Forced, and ServiceChangeReason is 905.
Issue 01 (2011-10-30)
15 Voice Feature
2.
The MG responds to the MGC with the Reply message. The MA5600T/MA5603T (MG) supports the registration and deregistration of not only an entire MG but also a single termination. The service status of a single user can be changed through the registration and deregistration of a single termination.
Authentication Mechanism of the H.248 Interface

Authentication is a security mechanism through which the MGC authenticates the legality of the MG user. The purpose of authentication is to prevent unauthorized entities from establishing illegal calls or interfering with legal calls through the H.248 or MGCP protocol. Authentication can be implemented only when it is also supported by the softswitch interconnected with the MG. l l In H.248, the implementation of authentication complies with RFC2402. MD5 is adopted as the encryption algorithm.
Figure 15-12 shows the authentication flow.
Figure 15-12 Authentication flow
The basic flow is as follows: 1. 2. 3. The MG sends the ServiceChange command to register with the MGC. The command contains the digital signature of the MG. After receiving the ServiceChange command, the softswitch verifies the MG and sends a reply. The softswitch sends the Modify message to the MG. The message contains the required algorithm ID and random number.
Issue 01 (2011-10-30)
15 Voice Feature
4. 5. 6.
The MG verifies the message sent by the softswitch and sends a reply. The softswitch authenticates the MG periodically. The MG sends replies to the softswitch.
15.6.3.2 H.248-Based VoIP

Figure 15-13 illustrates the principle of the call establishment and release in the H.248-based VoIP service. Figure 15-13 Principle of the VoIP feature that supports the H.248 protocol
Figure 15-14 illustrates the basic flow of a call establishment and release.
Issue 01 (2011-10-30)
561
15 Voice Feature
Figure 15-14 H.248-based call flow
1. 2. 3.
MG-0 detects the offhook of user A0, and notifies the MGC of the offhook event through the Notify command. After receiving the offhook event, the MGC sends a digitmap to MG-0, requests MG-0 to play the dial tone to user A0, and at the same time checks for the digit collection event. User A0 dials a telephone number, and MG-0 collects the digits according to the digitmap issued by the MGC. Then, MG-0 reports the result of digit collection to the MGC.
Issue 01 (2011-10-30)
15 Voice Feature
4. 5.
The MGC sends the Add command to MG-0 for creating a context and adding the termination and RTP termination of user A0 into the context. After creating the context, MG-0 responds to the MGC. The response contains the session description that provides the necessary information for the peer end to send the packet to MG-0, such as the IP address and UDP port number. The MGC sends the Add command to MG-1 for creating a context and adding the termination and RTP termination of user A1 into the context, and then issues the IP address/ UDP port number of user A0 to user A1. After creating the context, MG-1 responds to the MGC. The response contains the session description that provides the necessary information for the peer end to send the packet to MG-1, such as the IP address and UDP port number. MG-1 detects the offhook of user A1, and then reports the offhook event to the MGC. The softswitch (MGC) sends the Modify command to stop the ring back tone of user A0 and the ringing of user A1. The MGC sends the session description of MG-1 to user A0 through the Modify command. Then, the conversation is set up between users A0 and A1.
6.
7.
8.
9.
10. MG-0 detects the onhook of user A0, and notifies the MGC of the onhook event through the Notify command. 11. The MGC sends the Modify command to MG-0 and MG-1 respectively to modify the RTP mode to receive-only. 12. The MGC sends the Modify command to MG-1 requesting MG-1 to play the busy tone to user A1, and at the same time checks for the onhook event. 13. The MGC sends the Subtract command to MG-0, requesting MG-0 to release the resources that are occupied by the call of user A0. 14. MG-1 detects the onhook of user A1, and notifies the MGC of the onhook event through the Notify command. 15. The MGC sends the Subtract command to MG-1, requesting MG-1 to release the resources that are occupied by the call of user A1. 16. The call between users A0 and A1 is terminated, and all the resources occupied by the call are released.
15.6.3.3 H.248-Based MoIP

H.248 is similar to MGCP; therefore, for the core flow of the connection establishment and release of the H.248-based MoIP service, see MoIP (MGCP).
15.6.3.4 H.248-Based FoIP

H.248 is similar to MGCP; therefore, for the core flow of the H.248-based fax, see 15.5.3.3 MGCP-Based FoIP.
15.7 SIP Voice Services

This topic first describes the SIP protocol, and then describes in detail the principle of the SIP protocol.
Issue 01 (2011-10-30)
563
15 Voice Feature
15.7.1 Introduction
Definition
SIP is an application protocol for setting up, modifying, and terminating multimedia communication sessions or calls. The multimedia session can be a multimedia meeting, distance learning, or Internet telephony. SIP can be used for initiating sessions or inviting a member to join a session that has been set up otherwise. SIP transparently supports the mapping of names and the redirecting service, which facilitates the implementation of ISDN service, intelligent network, and personal mobile service. Once the session is set up, media streams are directly transmitted at the bearer layer through the Real-time Transport Protocol (RTP). SIP supports the following five features for the multimedia communication: 1. 2. 3. 4. 5. User location: determination of the end system used for the communication User capabilities: determination of the communication media and media parameters to be used User availability: determination of the willingness of the called party to join the communication Call setup: establishment of the call parameters of the calling party and called party Call processing: including transfer and termination of calls
SIP is a component of the IETF multimedia data and control architecture. Figure 15-15 shows the structure of the IETF multimedia data and control protocol stack. Figure 15-15 IETF multimedia data and control protocol stack
SIP can be used with the Resource Reservation Protocol (RSVP) for reserving network resources, with RTP for transporting real-time data and providing the QoS feedback, with the Real-Time Streaming Protocol (RTSP) for controlling the transport of real-time media streams,
15 Voice Feature
with the Session Announcement Protocol (SAP) for announcing multimedia sessions through multicast, and with the Session Description Protocol (SDP) for describing multimedia sessions. The functionality and implementation of SIP, however, does not depend on these protocols. SIP can also co-work with other call-establishing protocols and signaling protocols. In this case, an end system can obtain the address and protocol of the peer end through the SIP protocol by a specific address independent of the protocol. For example, through SIP, an end system can learn that the peer end is interoperable through H.323, and the end system can then obtain the H.245 gateway address and user address and set up a call by H.225.0. Or, through SIP, an end system can learn that the peer end is interoperable through PSTN, and SIP can specify the number of the called party and suggests that the call connection be set up through the Internet-to-PSTN gateway. SIP does not provide the conference control services, such as floor control or voting, and does not specify how the conference should be managed. SIP can be used to introduce some other session control protocols for the sessions. SIP does not allocate multicast addresses. SIP can invite users to join a session that has reserved or unreserved resources. SIP itself does not reserve resources, but it can convey necessary information to the invited party. By using the SIP protocol gateway to realize the interoperability between the Internet and the PSTN/ISDN network, calls can be implemented between the POTS users who are connected through the Internet, and between POTS users and Internet phone users. The SIP protocol gateway interoperable with H.323 can also be designed. SIP is a text-based protocol put forth by IETF for IP phone/multimedia conferencing. It is a light-weight signaling protocol and has the following features: 1. 2. Minimum status: One conference call or phone call can contain one or multiple requests or transactions. The proxy server can work in the stateless mode. Irrelevance with lower layer protocols: SIP has minimum assumption of the lower layer protocols. The lower layer protocols can provide reliable or unreliable services to the SIP protocol layer, which can be packet or byte stream services. On the Internet, the SIP protocol layer can use the UDP or TCP protocol, and UDP is preferred. When UDP is not available, TCP is used. Text-based: SIP adopts the text-based UTF-8 coding format and uses the ISO 10646 character set, which makes it easy to realize programming languages such as Java. This feature brings about merits such as easy commissioning, flexibility, and extensibility. The length of message, however, may also increase. For this reason, the message format is particularly designed so that the SIP messages are easy to parse. Robustness: The robustness of SIP is demonstrated in several facets. For example, the proxy server needs not maintain the call status, subsequent requests and re-transmission can adopt different routes, and the response message is transmitted in the self-routing mode. Extensibility: The extensibility of SIP is demonstrated in several ways. Unidentifiable header fields can be ignored, the user can specify the message content that the SIP server must understand, new header fields can be introduced easily, and status codes are encoded in the layered coding mode. Readiness to support IN services: Working with the end system, SIP and other call control extended protocols can support most services in Capability Set 1 and Capability Set 2 of ITU-T.
3.
4.
5.
6.
Purpose
SIP will revolutionize the mode of communication service provisioning and the users' habit of communication consumption. An innovating communication mode integrating video phone
15 Voice Feature
service, messaging, Web service, e-mail, synchronous browsing, and conference call will be introduced to the telecommunication industry. Adopting SIP as the control layer protocol has the following advantages: 1. Based on an open Internet standard, SIP has inherent benefits in the integration and interoperability of voice and data services. SIP can implement across-media and acrossdevice call control, and supports various media formats. SIP also supports dynamic adding and deleting of media streams, which makes it easier to support richer service features. SIP is intelligently extensible to the service and terminal side, thus reducing the network load and facilitating the provisioning of service. SIP supports mobile functions at the application layer, including the dynamic registering mechanism, location management mechanism, and redirecting mechanism. SIP supports features such as presence, fork, and subscription, which facilitates development of new services. As a simple protocol, SIP has generally acknowledged extensibility.
2. 3. 4. 5.

l l RFC 3262: Reliability Of Provisional Responses in the Session Initiation Protocol (SIP) RFC 3263: SIP Locating SIP Servers
15.7.3 Principle
15.7.3.1 SIP User Identification
The SIP user ID can be SIP URI or TEL URI, either of which identifies a SIP user uniquely. The SIP user ID must be the same on the MG and the MGC. SIP URI is used in the SIP message, indicating the initiator of request (From), the current destination address (Request-URI), the final receiver (To), and the address after redirection (Contact). SIP URI can also be embedded into the Web page or other hyper links to indicate that a certain user or service can be accessed through SIP. When embedded into a hyper link, SIP URI indicates the INVITE mode. It is presented as follows: SIP-URI="sip:"[ userinfo "@" ]hostport For example: sip:j.doe@big.com sip:+1-212-555-1212:1234@gateway.com;user=phone sip:1212@gateway.com sip:alice@10.1.2.3 sip:alice@example.com sip:alice%40example.com@gateway.com
TEL URI (telephone URI) indicates the resources represented by a telephone number, which can be a global or local number. The global number complies with the E164 encoding scheme,
15 Voice Feature
starting with +. The local number complies with the local proprietary coding scheme. The formats are as follows: tel:+86-755-6544487 tel:45687; phonecontext = example.com tel:45687; phonecontext = +86-755-65
15.7.3.2 SIP Message Format Format

The SIP message is encoded in the text format, each line ending with CR or LF. The SIP message has two types, the request message and the response message. The message format is as follows: SIP message = Start-line *Message header field Empty line (CRLF) [Message body] Start-line = Message header = Request line | Status line (General header field| Request header field| Response header field| Entity header field)
Request Message
The MA5600T/MA5603T supports the following SIP request messages: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, PRACK, and UPDATE. Table 15-5 lists the functions of the request messages.
Table 15-5 SIP request messages Type of Request Message INVITE ACK OPTIONS BYE CANCEL REGISTER
Issue 01 (2011-10-30)
Function Invites a user to join a call Acknowledges the response message of the request Requests for the capability information Releases an established call Releases an unestablished call Registers the user location information on the SIP network server
567
15 Voice Feature
Type of Request Message PRACK UPDATE
Function Acknowledges a reliable provisional response message Updates the session
Response Message
The SIP response message is used for responding to the SIP request message, indicating whether the call is successful or fails. Different types of response messages can be distinguished by the status code. A status code contains three integers. The first integer defines the type of the response message, and the other two integers further define the details of the response message. Table 15-6 lists the types of response messages. Table 15-6 SIP response messages 1XX 2XX 3XX 4XX 5XX 6XX Informational Success Redirection Client Error Server Error Global Failure Provisional Final Final Final Final Final
l l l l l l l l
Provisional indicates that the call is in process. Final is used to terminate the request message. 1xx indicates that the request message is received and is being processed. 2xx indicates that the request message is received, processed, and accepted. 3xx indicates that further actions are required for finishing processing the request message. 4xx indicates that the request message contains syntax errors or that the SIP server fails to process the request message. 5xx indicates that the SIP server is faulty and fails to process the request message. 6xx indicates that the request message cannot be processed by any SIP server.
SIP requires that the application must understand the first integer of the response status code, and allows the application not to process the last two integers of the status code.
15.7.3.3 User Registration Flow

The registration has two types, the registration through unsafe connection (not requiring authentication) and the registration through safe connection (requiring authentication). After the system is powered on or after the user is added, the user registration flow is started.
15 Voice Feature
Registration Through Unsafe Connection

Figure 15-16 Flowchart of the registration through unsafe connection
As shown in Figure 15-16, the SIP AG sends the REGISTER request message to the IMS for each user. The message contains information such as the user ID. After receiving the REGISTER request message, the IMS checks whether the user is already configured on the IMS. If the user is already configured, the IMS responds to the SIP AG with the RESPONSE 200 message.
Registration Through Safe Connection

Figure 15-17 Flowchart of the registration through safe connection
Issue 01 (2011-10-30)
569
15 Voice Feature
As shown in Figure 15-17, the SIP AG sends the REGISTER request message to the IMS for each user. The message contains information such as the user ID. The IMS responds with the RESPONSE 401/407 message, the message containing information such as the key and the encryption mode. The SIP AG encrypts the corresponding user name and password, generates a new REGISTER request message, and sends the message to the IMS. The IMS decrypts the message and verifies the user name and password. If the user name and password are correct, the IMS responds to the SIP AG with the RESPONSE 200 message.
15.7.3.4 Call Flow of the VoIP (SIP) Calling Party

Figure 15-18 shows the common call flow based on the SIP protocol for a VoIP calling party.
Issue 01 (2011-10-30)
570
15 Voice Feature
Figure 15-18 SIP-based call flow for a VoIP calling party
AG: Access Gateway P-CSCF-O: Proxy-CSCF-Originating Network
CSCF: Call Session Control Function
Issue 01 (2011-10-30)
571
15 Voice Feature
l l l
P1: The AG receives the offhook message of the calling party and plays the dial tone to the calling party. P2: The AG receives the first dialed digit, stops playing the dial tone, and then starts matching the digit with the digitmaps. P3: After receiving N dialed digits and matching the digits with the digitmaps, the AG finds that the dialed number matches a certain digitmap. Then, the AG generates the INVITE message and sends the message to P-CSCF-O. P4: The AG receives RESPONSE 100 and knows that the peer end receives the INVITE message, so the AG stops the INVITE message re-transmitting flow. P5: The AG receives 180, which indicates that the phone of the called party is ringing. Then, the AG plays the ring back tone to the calling party. P6: The AG receives 200, which indicates that the called party answers the phone, so the AG stops playing the ring back tone to the calling party, and changes the stream mode to the bi-directional mode. Then, the AG generates the ACK message and sends the message to P-CSCF-O.
l l l
The preceding flow is for the call in normal conditions. The scenario may vary. That is, when the calling party initiates a call, P-CSCF-O determines the situation as follows: l l If the calling party is configured but is not registered on P-CSCF-O, P-CSCF-O rejects the calling party and responds with 403 to the AG. If the calling party is configured, P-CSCF-O rejects the calling party and responds with 404 to the AG.
15.7.3.5 Call Flow of the VoIP (SIP) Called Party

Figure 15-19 shows the common call flow based on the SIP protocol for a VoIP called party.
Issue 01 (2011-10-30)
572
15 Voice Feature
Figure 15-19 SIP-based call flow for a VoIP called party
AG: Access Gateway P-CSCF-T: Proxy-CSCF-Terminating Network
CSCF: Call Session Control Function
P1: The AG receives the INVITE message from P-CSCF-T, generates the RESPONSE 100 message, and sends the message to P-CSCF-T. According to the P-Called-Party-ID header field, RequestURI, and TO header field that are contained in the INVITE message, the AG locates the called party. If the user is identified by TEL URI, the AG can locate the called party through the telephone number contained in TEL URI instead of through the header fields. After locating the called party, the AG plays the ringing tone to the called party,
Issue 01 (2011-10-30)
15 Voice Feature
generates the RESPONSE 180 message, and sends the message to P-CSCF-T, informing P-CSCF-T that the phone of the called party is ringing. l P2: After receiving the offhook message of the called party, the AG stops playing the ringing tone, generates the 200 message, and sends the message to P-CSCF-T informing P-CSCFT that the called party answers the phone. P3: The AG receives the ACK message. Then, the calling party and called party are engaged in the conversation.
The scenario may vary. That is, the AG receives the INVITE message and determines the situation as follows: l l If the called party is configured but is not registered on the AG, the AG rejects the calling party and responds with 403 to P-CSCF-T. If the called party is configured on the AG, the AG rejects the calling party and responds with 404 to P-CSCF-T.
15.7.3.6 Call Releasing Flow

Figure 15-20 shows the call releasing flow. Figure 15-20 Call releasing flow
P1: The AG receives the onhook message of the user, generates the BYE request message, and sends the message to P-CSCF. Then, the AG releases the DSP resource that is allocated to the user for the call. P2: The AG receives the 200 message from P-CSCF.
15.7.3.7 SIP-Based FoIP

In terms of transmission protocol, the fax service can be classified into transparent transmission and T.38; in terms of switching mode, the fax service can be classified into auto-switching and negotiated-switching. Hence, there are four combinations of the fax mode: auto-switching transparent transmission, auto-switching T.38, negotiated-switching transparent transmission, and negotiated-switching T.38.
15 Voice Feature
The working principle of auto-switching is that the AG detects the fax tone, and then selects the transparent transmission or T.38 mode according to the configuration. In this case, the AG needs not send any signaling to the peer device. The working principle of negotiated-switching is that the AG detects the fax tone, and according to the configuration sends the peer end the re-INVITE message that contains the negotiation parameters for negotiating the fax mode. In actual application, fax can also be classified into low-speed fax and high-speed fax in terms of transmission speed. The high-speed fax cannot adopt the T.38 mode. A high-speed fax machine can actually be regarded as a modem. With the speed reduced, a high-speed fax machine can also adopt the T.38 mode.
Flow of the Negotiated-Switching Transparent Transmission Fax

Currently, this fax mode can be presented in three ways. l l l Presented as a=fax. This is a G.711 transparent transmission fax mode proposed by China Telecom. Presented as a=silenceSupp:off. This is a G.711 transparent transmission fax mode defined in the draft-IETF-sipping-realtimefax-01.txt. Presented as a=gpmd:99 vbd=yes. This is a VBD mode defined in the ITU-T V.152.
Which method to be applied depends on the parameters configured. Figure 15-21 shows the fax flow. Figure 15-21 Flow of the negotiated-switching transparent transmission fax
Issue 01 (2011-10-30)
575
15 Voice Feature
l l
P1: AG-T first detects the fax tone, and then sends the re-INVITE message to the AG (AGO) to which the calling party is connected. L1: The SDP message contained in the re-INVITE message has three types. The specific fax mode must be configured on the AGs. The initiator of negotiation uses the a parameter of different values, and the recipient of negotiation needs to be compatible with the three parameter values. This means that when the recipient receives the re-INVITE message, the recipient should be able to complete the negotiation process with the initiator regardless of the a parameter value. The G.711 transparent transmission fax/modem mode defined in the draft-IETFsipping-realtimefax-01.txt. The G.711 transparent transmission fax/modem mode proposed by China Telecom. The VBD mode defined in the ITU-T V.152.
l l l l l l
P2: AG-O receives the re-INVITE message. Then, AG-O generates the 200 OK message and sends the message to AG-T. P3: AG-T receives the 200 OK message, and also enables the DSP channel in the fax mode. P4: AG-T receives the fax end signal, and sends the re-INVITE message to AG-O. L2: The SDP message contained in the re-INVITE message is for setting up a common voice channel. P5: AG-O receives the re-INVITE message and switches the DSP channel to the voice mode. P6: AG-T receives the 200 OK message, and also switches the DSP channel to the voice mode.
Flow of the Negotiated-Switching T.38 Fax

Figure 15-22 shows the flow of the negotiated-switching T.38 fax.
Issue 01 (2011-10-30)
576
15 Voice Feature
Figure 15-22 Flow of the negotiated-switching T.38 fax
l l l
P1: AG-T first detects the fax tone, and then sends the re-INVITE message to the AG (AGO) to which the calling party is connected. L1: The SDP message contained in the re-INVITE message carries the T.38 information. P2: AG-O receives the re-INVITE message, learns that the peer device requires the T.38 mode, and enables the DSP channel in the T.38 mode. Then, AG-O generates the 200 message and sends the message to AG-T. P3: AG-T receives the 200 OK message, and also enables the DSP channel in the T.38 mode. P4: AG-T receives the fax end signal, and sends the re-INVITE message to AG-O. L2: The SDP message contained in the re-INVITE message is for setting up a common voice channel. P5: AG-O receives the re-INVITE message and switches the DSP channel to the voice mode. P6: AG-T receives the 200 OK message, and also switches the DSP channel to the voice mode.
NOTE
l l l l l
Figure 15-23 and Figure 15-24 shows the fax flows when the peer device does not support the T.38 mode.
Issue 01 (2011-10-30)
577
15 Voice Feature
Figure 15-23 Flow of the negotiated-switching T.38 fax when the peer device does not support the T.38 mode (scenario 1)
Issue 01 (2011-10-30)
578
15 Voice Feature
Figure 15-24 Flow of the negotiated-switching T.38 fax when the peer device does not support the T.38 mode (scenario 2)
In scenario 1, if AG-O does not support T.38, it may respond with 415 Unsupported Media Type. After AG-T receives the 415 response, AG-T sends the BYE message and releases the current call. In scenario 2, if AG-O does not support T.38, it responds with 488 Not Acceptable Here or 606 Not Acceptable. After AG-T receives the 488/606 response, AG-T generates another reINVITE message. The SDP message in this message contains the VBD media type. Thus, the negotiation on the T.38 mode fails, and the transparent transmission mode is adopted. The MA5600T/MA5603T supports the T.38 mode, and therefore does not respond with the 415/488/606 message in the T.38 negotiation. The MA5600T/MA5603T, however, can process such error codes sent by the peer device.
Issue 01 (2011-10-30)
579
15 Voice Feature
Flow of the Auto-Switching Transparent Transmission Fax

Generally, the called fax terminal detects the fax tone on the TDM side first, and the calling fax terminal detects the fax tone sent from the IP side. The fax terminal that detects the fax tone automatically switches to the transparent transmission mode without the SIP negotiation. One problem currently exists in the auto-switching fax flow: If the DSP channel originally works in the G.729 mode for the voice service, and is now switched to the G.711 transparent transmission mode when the fax tone is detected, the G.711 voice packet may not be recognized. This is because the DSP channel of the calling party stills works in the G.729 mode. Therefore, the DSP chip is required to be able to receive G.711 packets when working in the G.729 or other coding modes. The prerequisite remains that the DSP chip should detect and report the fax tone sent from the IP side.
Flow of the Auto-Switching T.38 Fax

The working principle of this fax flow is the same as the working principle of the auto-switching transparent transmission fax. The difference is that, after the fax tone is detected, the DSP channel is enabled in the T.38 mode instead of the transparent transmission mode.
15.7.3.8 SIP-Based MoIP

In terms of service flow, the modem service is similar to the transparent transmission fax service, and can also be classified as auto-switching and negotiated-switching. The modem service in the negotiated-switching transparent transmission mode can be presented in three ways. l l l Presented as a=modem. This is a G.711 transparent transmission modem mode proposed by China Telecom. Presented as a=silenceSupp:off. This is a G.711 transparent transmission modem mode defined in the draft-IETF-sipping-realtimefax-01.txt. Presented as a=gpmd:99 vbd=yes. This is a VBD mode defined in the ITU-T V.152.
The method actually applied depends on the parameters configured.
Flow of the Negotiated-Switching Modem Service

Figure 15-25 shows the flow of the negotiated-switching modem service.
Issue 01 (2011-10-30)
580
15 Voice Feature
Figure 15-25 Flow of the negotiated-switching modem service
l l
P1: AG-T first detects the modem tone, and then sends the re-INVITE message to the AG (AG-O) to which the calling party is connected. L1: The SDP message contained in the re-INVITE message has three types, corresponding to the three preceding presentations of the negotiated-switching transparent transmission mode. The specific transparent transmission modem mode must be configured on the AGs. P2: AG-O receives the re-INVITE message. Then, AG-O generates the 200 message and sends the message to AG-T. P3: AG-T receives the 200 OK message, and also enables the DSP channel in the fax or modem mode.
l l
Auto-Switching Modem Mode

In this mode, after the AG detects the modem tone, the AG automatically switches the DSP channel to the VBD mode without notifying the IMS or the peer device. Generally, the called modem detects the modem tone on the TDM side first, and the calling modem detects the modem tone sent from the IP side. The modem that detects the modem tone automatically switches to the VBD mode without the SIP negotiation.
Modem Redundancy Transmission

The modem redundancy transmission is currently implemented through RFC2198. The DSP chip on Huawei device already supports the modem service using RFC2198. Only one redundancy packet is supported, however.
15.8 Key Voice Feature

This topic provides the overview of key voice features and then describes working principle of each sub feature in detail.
15 Voice Feature
15.8.1 Introduction
Definition
Key voice features are a series of technologies adopted to deliver high-quality voice services. Examples of these technologies are the voice codec, Echo Canceller (EC), and Voice Activity Detection (VAD).
Purpose
The purpose is to deliver high-quality voice services.
15.8.2 Codec and Packetization Duration

Introduction
Codec is a key technology of voice services. Coding means that the DSP encodes the TDMbased voice data, assembles the data into packets, and then sends the packets to the IP network. Decoding means that the DSP decodes the voice packets received from the IP network and plays the voice to the TDM side. Frequently-used codec types are G.711A, G.711Mu, G.729, G.723.1Low, and G.723.1High. G. 711A and G.711Mu are lossless coding schemes. G.729, G.723.1Low, and G.723.1High are lossy compressed coding schemes. The compressed coding schemes require less bandwidth, but the voice quality is poor and the delay is large. (G.711 delivers the best voice quality but requires a bandwidth of 64 kbit/s. G.723 requires less bandwidth but the voice quality is less satisfying.) PTime is the interval at which the DSP assembles the voice data into packets. It varies according to the codec type. Table 15-7 lists the codec types. Table 15-7 Codec list Codec Type G.711A/Mu G.729a G.723.1High G.723.1Low Coding Rate (kbit/s) 64 8 6.3 5.3 PTime and Packet Size (including the RTP header, UDP header, IP header, and Ethernet header) 20 ms, 214 bytes 20 ms, 74 bytes 30 ms, 78 bytes 30 ms, 74 bytes
Specifications
The 64-line G.711A, G.711Mu, and 32-line G.729a are supported.

ITU-T G.711, ITU-T G.729, and ITU-T G.723
15 Voice Feature
15.8.3 Echo Canceller

Introduction
Echo is classified into the acoustic echo and electrical echo. l Acoustic echo Acoustic echo refers to the echo reflected by an obstacle when the voice encounters the obstacle in the transmission path. For example, if you place the phone at one side and speak at the other side, you can hear your own voice. This is because the voice is transmitted through the table and reflected from the collector to the receiver of the phone. Currently, the VoIP DSP chip does not support cancellation of the acoustic echo because it cannot distinguish the normal voice from the acoustic echo. l Electrical echo Electrical echo is generated by the 2-wire/4-wire converter on the service board, because the impedance matching is not ideal on the 2-wire/4-wire converter. EC generally refers to the cancellation of the electrical echo. Figure 15-26 shows how the electrical echo is generated. Figure 15-26 Generation of the electrical echo
In the PSTN network, owing to the small delay, the voice and the echo reach the ears of the speaker almost at the same time. Therefore, the echo can hardly be perceived. In the VoIP network, owing to the large delay, the echo reaches the ears some time after the voice is heard. Therefore, the echo can be easily perceived. As described in ITU-T G.131 and ITU-T G.161, the echo can be perceived when the echo delay exceeds 25 ms. Figure 15-27 shows how the EC is implemented.
15 Voice Feature
Figure 15-27 Implementation of the EC function
Rin is the voice received from the remote end. Rin is the input of the wave filter and the output of the wave filter is the simulated echo g. Rin is converted into the echo G on the 2-wire/4-wire converter. S is the local-end voice, that is, the voice received by the local receiver. The localend voice S is overlaid with the echo G, resulting in the input signal of the EC, Sin. The EC removes the simulated echo g from the input signal Sin to obtain the output signal Sout. Sin = S + G Sout = Sin - g = S + G - g Gg Therefore, Sout S
Specifications
Enabling or disabling the EC and the 64-ms tail delay are supported. Enabling or disabling the EC is supported and the supported maximum EC duration is 128 ms.

ITU-T G.168, ITU-T G.131, and ITU-T G.161
15.8.4 Non-Linear Processor

Introduction
Owing to various reasons, the EC cannot cancel all the echoes. To improve the EC performance, a non-linear processing (NLP) is performed on the remaining echoes when the power of the remaining echoes is lower than a preset value. This can further reduce the power of the remaining echoes. A simple method is to replace the remaining echoes with the silence when the power of the remaining echoes is lower than the threshold.
15 Voice Feature
Specifications
The NLP function can be enabled or disabled by configuring the DSP profile on a port. If the DSP profile is not configured, the system automatically enables or disables the NLP function according to the service mode. Specifically, for the voice service, the system enables the NLP function; for the fax or modem service, the system disables the NLP function.
Impact
The NLP function must be disabled in the case of FoIP or MoIP.

ITU-T G0.168, ITU-T G0.131, and ITU-T G0.161
15.8.5 VAD
Introduction
The VAD is used to reduce the consumption of the network bandwidth. Input signals of phones are classified into the voice signals and the silence signals. The VAD is used to distinguish the voice signals from the silence signals based on the energy of the signals. The VAD is often used together with the silence compression. For example, after the VAD is enabled, the DSP sends the RTP packets to the remote end when it detects the voice. The DSP does not send the RTP packets to the IP network when it detects the silence. The DSP sends a silence ID (SID) to the remote end only when the background noise changes. Based on the received SID, the remote DSP generates the background noise, thus saving the network bandwidth when the silence signals are transmitted. In a conversation, only 40% of signals are valid voice signals. Therefore, enabling the VAD can substantially reduce the consumption of the network bandwidth when the network resources are insufficient.
Specifications
Enabling or disabling the VAD is supported. Sending and receiving the SID packets are supported.

ITU-T G.711 and ITU-T G.729
15.8.6 Packet Loss Concealment

Introduction
When a network or a device loses packets, the voice quality deteriorates. In practice, packet loss is inevitable. If the PLC is enabled to compensate the signals, however, the impact of packet loss on the voice quality is reduced and the success rates of FoIP and MoIP services increases in the case of packet loss. Three compensation modes are available:
15 Voice Feature
l l l
Compensate the lost packet with the silence. Compensate the lost packet with the previous packet. Compensate the lost packet with a similar packet that is calculated based on the energies of the previous packet and the subsequent packet (as described in G.711 Appendix I).
The third mode consumes the most DSP resources, but improves the voice quality in the most satisfying manner. The first mode consumes the least DSP resources, but improves the voice quality in the least satisfying manner.
Specifications
Enabling and disabling the PLC and configuration of the compensation mode described in G. 711 Appendix I are supported. By default, the mode of compensating the lost packet with the previous packet is adopted.

G.711 Appendix I
15.8.7 Jitter Buffer

Introduction
The transmission quality on the IP network is not guaranteed. The interval at which packets are received from the remote end is not even, and the sequence of packets received may be different from the sequence that these packets are sent. As a result, the voice quality is degraded. Therefore, the JB is introduced to eliminate the jitter of the IP network. The basic idea of JB is to restore the sequence of packets by increasing the delay and reduce the packet loss rate. The JB is classified into the dynamic JB and the static JB. During a conversation, it is possible that the network jitter is not serious or even does not occur in a period of time and is serious in another period of time. The dynamic JB can adjust the depth of the buffer based on the severity of the network jitter. In this way, when the jitter is not serious, the introduced delay is also small. When the jitter is serious, a sufficient buffer depth is available to eliminate the jitter. The static JB must be adopted for data services such as the FoIP and MoIP, because adjustment of the JB may cause packet loss and packet loss has a great impact on data services.
Specifications
The dynamic JB and the static JB are supported. The adjustable range of the JB depth is 0 ms to 135 ms.
15.8.8 Dual Tone Multi Frequency

Introduction
DTMF means that the tones of two frequencies are overlaid to represent a number, as shown in Table 15-8.
15 Voice Feature
Table 15-8 Mapping between frequencies and numbers Unit: Hz 697 770 852 941 1209 1 4 7 * 1336 2 5 8 0 1477 3 6 9 # 1633 A B C D
When numbers are dialed on the phone, the dialed numbers are converted into the dual-frequency overlay tones. The DSP detects the dialed numbers by checking the DTMF. The supported DTMF-specific functions are as follows: l l l DTMF erasure: After the DSP detects DTMF signals, it erases the DTMF signals from the RTP media stream. DTMF transparent transmission: After the DSP detects DTMF signals, it retains the DTMF signals in the RTP media stream. DTMF RFC2833 transmission: After the DSP detects DTMF signals, it erases the DTMF signals from the RTP media stream and sends the DTMF information in RFC2833 transmission mode.
Specifications
Detection and sending of the DTMF signals is supported. Configuration of DTMF-specific functions (device-based) is supported.

ITU-T Q.24
15.8.9 Tone Playing

Introduction
Tone files are stored on the flash memory of the control board. The file name is generally voice.efs. The tone file contains the description about the tone types supported by the DSP. The description covers the information such as the signal tone type, frequency, duration, and strength. After the system initiation is complete, the tone playing parameters are configured on the DSP. When requested to play the tone for a subscriber, the DSP reads the configuration and generates the signal tone that should be played to the subscriber on a real-time basis. Tone files are classified into the parameter tone, waveform tone, and announcement. The parameter tone is a type of simple tones, such as the dialing tone, busy tone, and ring back tone. The information about the frequency, energy, duration, and beat of the parameter tone are sent to the DSP and then the DSP generates the parameter tone accordingly. The waveform tone is a type of simple tones, such as the dialing tone, busy tone, and ring back tone. These tones are recorded, converted into the PCM data, and stored in the logic. The logic
15 Voice Feature
cyclically plays the data of a type of tones on a TDM timeslot. When a tone should be played to a subscriber, the timeslot mapping the subscriber is connected to the timeslot, on which the logic plays the tone. The parameter tone takes precedence over the waveform tone. The waveform tone is used only when the DSP is faulty or when the DSP resources are not available. The announcement is a type of messages played to subscribers, such as "The subscriber you dialed is busy, Please call later". The message to be played is recorded and stored on the DSP. When an announcement should be played to a subscriber, the logic or the DSP plays the recorded announcement to the subscriber.
Specifications
l l l Playing of parameter tones, waveform tones, and announcements is supported. Storage of 1-MB announcement data on the DSP is supported. Simultaneous playing of announcements for 64 subscribers is supported.
15.8.10 Voice Quality Enhancement

Introduction
The VQE feature is applicable to voice services in the noisy public areas, such as the roads, docks, scenic spots, and bus stations. Deployment of VQE in these areas can improve the voice quality and user experience. The VQE consists of two functions, automatic gain control (AGC) and spectral noise suppression (SNS). AGC refers to the automatic adjustment of the output gain based on the preset target value of the gain during the VoIP communication process. In this way, listeners are free from the discomfort caused by the sudden change in the background noise. AGC provides smooth adjustment of the energy and prevents the sudden change in the output energy. SNS refers to the reduction of the energy of the background noise based on the preset target value of background noise suppression through the background noise detection during the VoIP communication process. With the SNS function, listeners feel more comfortable with the conversation and the conversation is better understandable.
Specifications
At present, only the AGC function is supported. The VQE feature is based on the configuration of the user port. After the parameter configuration is complete, the configuration takes effect on the next call. At present, the VQE function takes effect only when the G.711 codec is used. It does not take effect when other codecs, such as G.729 and G.723, are used. If the VQE function is configured when a codec other than G.711 is used, the configuration does not take effect and the prompt is not given.
15.8.11 Fax/Modem Quality Enhancement

Overview
After the IP network takes the place of the PSTN network, the use of fax and modem on the VoIP network becomes more and more popular. Therefore, the AG is required to provide
15 Voice Feature
applications similar to those of the PSTN network. Currently, the Voice Band Data (VBD) transparent transmission is adopted by the medium gateway (MG) in the application of the fax and modem. Transparent transmission, however, relies heavily on the bearer network and deterioration of the network quality may lead to service failures. The enhanced quality feature of the fax and modem is mainly used to improve the put-through rate and online duration of the fax and modem services. For example, if POS terminals are connected to a modem in a shopping mall or a bank, the fax/modem quality enhancement feature can be used to improve the stability and online duration of the Modem, thus preventing the disconnection caused by the poor network quality. The fax/modem quality enhancement feature consists of the RFC2198 intelligent startup function and the packetization at the interval of 10 ms. After the fax/modem quality enhancement feature is enabled, the RFC2198 function and the packetization at the interval of 10 ms are automatically started. The RFC2198 standard uses the data stream redundancy mechanism to prevent the packet loss of the network from degrading the service quality. When the average consecutive packet loss ratio is low, the receiver can reassemble and restore the lost packet based on the redundant packets in the later received packets. The audio redundancy mechanism described in RF2198 can be used to restore the events lost in the packets, while the mode described in RFC2833 can be used to process the DTMF signals transmitted through the RTP packets. Information carried by packets assembled every 10 ms is less the information carried by packets assembled every 20 ms. Therefore, in case of packet loss, the packetization at the interval of 10 ms causes less impact on services that the packetization at the interval of 20 ms. Table 15-9 lists the test data recorded before and after the quality enhancement feature is enabled. The data shows that stability of services improves substantially after the quality enhancement feature is enabled. Table 15-9 Test data before and after the quality enhancement Modem PTime Network Packet Loss Ratio (Random) 0.10% 20 ms 0.50% 1.00% 1.00% (rfc2198) 0.10% 10 ms 0.50% 1.00% 1.00% (rfc2198) Online Duration 22 hours 1.5 hours Unavailable 12.5 hours > 24 hours 22.5 hours 5.5 hours 24 hours
T336CX
Specifications
The fax/modem quality enhancement is supported.
15 Voice Feature
15.8.12 RFC2833 Encryption

Background
On the NGN network, the voice and DTMF signals are encapsulated as the IP packets before they are sent over the IP network. The DTMF signals are sent in the RTP packets of the voice in two modes: l The DTMF signals are sent as the RTP media stream on the NGN network. That is, the sending media gateway (MG) measures the frequencies of the DTMF signals and sends the measurement result to the receiving MG through RTP packets. In this transmission mode, the receiving MG processes the DTMF signals as the voice signals. If the voice signals are damaged, the receiving MG cannot detect the DTMF signals in the media stream. Therefore, this DTMF transmission mode is not recommended when the network quality is poor or when the compressed codecs (such as G.723.1 and G.729) are used. The DTMF signals are sent in RFC2833 mode on the NGN network. In this case, the sending MG must be equipped with the digital signal processor and the related algorithm, so that it can detect the DTMF signals, translate the data into the number, and send the number through the RFC2833 packets. The receiving MG identifies the DTMF signals in the RFC2833 packets and performs further processing.
Regardless of the transmission mode, the DTMF signals are sent in plain text over the IP network. Owing to the openness of the IP network, it is easy for network hackers to intercept the IP packets and analyze the IP packets to obtain the voice and DTMF information carried by the IP packets. For example, the customer information is contained in the DTMF signals during the telephone banking service. If the DTMF packets in the two-stage dialing are sent without being encrypted, it is easy for hackers to intercept the customer information of the bank. The leakage of the customer information is devastating for banks.
Introduction to the RFC2833 Standard

RFC2833 specifies the methods for transmitting the DTMF signals, other telephony tones, and telephony signals through the RTP packets. When the DTMF signals are sent in RFC2833 mode, the MG identifies the DTMF signals, translates them into the corresponding numbers, assembles the number into RFC2833 packets, and then sends the packets to the receiving end. The receiving end restores the DTMF signals based on the numbers in the RFC2833 packets.
Implementation of RFC2833 Encryption

The RFC2833 encryption function of the MG is configured on the softswitch. The softswitch sends the key to the sending and receiving MGs and the two MGs send the key to the DSP. The DSP on the sending MG detects the DTMF signals, erases the DTMF signals from the media stream, assembles the DTMF signals in the RFC2833 packets, and encrypts the RFC2833 packets based on the key sent by the softswitch. The DSP on the receiving MG decrypts the RFC2833 packets based on the key sent by the softswitch, obtains the DTMF information, and restores the DTMF signals. The Huawei proprietary algorithm, NGN Cipher Version 1 (HNC1), is adopted. It supports the 128-bit to 256-bit key. The dynamic key mechanism ensures the security of the key. The key is controlled by the softswitch, updated dynamically at each call, encrypted and sent through the SDP packets in compliance with the H.248/MGCP protocol.
15 Voice Feature
With the RFC2833 encryption function, the transmission security of the DTMF information is ensured. This encryption function is implemented jointly by the MA5600T/MA5603T and the Huawei MSOFTX3000.

RFC2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
15.8.13 RTCP XR
Introduction
If RTCP is enabled for an RTP session, the information about the number of RTP packets sent or received by one end is sent to the peer end at a specific interval through the RTCP packet. In this way, the peer end knows the number of packets that should be received at this interval and learns about the network packet loss situation by comparing this number with the number of packets that are actually received. RTCP XR is an extended protocol of the RTCP. The information about the simulated line energy, noise energy, R-factor, and mean opinion score (MOS) is added to RTCP XR.

RFC 3611 ITU-T G.107
15.9 Voice Interface Feature

This topic describes the features in relation to the voice interface, including basic features such as ringing and Z interface and enhanced features.
15.9.1 Introduction
Definition
Voice interface features are the features implemented on the voice interface.
Purpose
The purpose is to provide the standard-compliant voice interface that has the reliable protection capability and intelligent energy-saving function.
15.9.2 Ringing
Ringing signals are generated by the service board. Currently, 13 ringing modes are predefined and 16 ringing modes can be customized. Table 15-10 lists the predefined ringing modes.
Issue 01 (2011-10-30)
591
15 Voice Feature
Table 15-10 Predefined ringing modes Ringing Mode ID 0 1 2 3 4 5 6 8 9 10 11 12 13 Description Normal Ring 1:4 Special Ring 1:2 Special Ring 0.4:0.2:0.4:4 Long Ring Special Ring 1.2:2 HK Ring 1:3 HK CNTRX 0.4:0.2:0.4:0.2:0.4:3.0 HK DN-A 0.4:0.2:0.4:3.0 HK ACB 0.4:0.2 HK Reminder (one sound every 0.4 second) HK DN-B 1.2:3 CNTRX_IN 0.4:0.2:0.4:0.2:0.4:2.6 Long distance Ring 2:1 (for Egypt)
A maximum of 16 ringing modes can be customized. Each customized ringing mode can be configured with up to three ringing sections. As shown in Figure 15-28, a, c, and e are the ringing sections; b, d, and f are the pause sections. The maximum duration of each ringing or pause section is 25.6 seconds. Figure 15-28 Configuration of the customized ringing mode
T a b c d e f
15.9.3 Interface Protection

Introduction
Service boards are connected to user terminals through subscriber cables. Some subscriber cables may be routed under the ground or overhead and some may be routed in parallel with the mains AC power cables. In these cases, a high voltage may be generated on subscriber cables because of the lightning attack, contact with power lines, and induction of power lines. The high voltage may damage the ports on service boards. Therefore, service boards must be equipped with the protection capability to prevent occurrence of the preceding problems.
15 Voice Feature
Version Support
The MA5600T/MA5603T fully complies with the requirements specified in the ITU K20/K45. The protection standards formulated by Huawei are stricter than the requirements specified in the ITU K20/K45. For example, the ITU requires that ports can withstand a voltage of 1500 V when the level-1 protection is not available. Tests show that Huawei boards generally can withstand a voltage of 4000 V when the level-1 protection is not available.

ITU K20/K45
15.9.4 Features of the Voice Line Interface

Standards of the Voice Line Interface
Major standards of the voice line interface are as follows: l l l ITU-Q552: It defines transmission specifications of the Z interface. ES 201970: It defines basic hardware features of the voice interface. YD751 - Network Entry Checking Methods for Telephone Exchange Equipment: It describes the voice interface standards defined by China.
The voice technologies have gone through a long period of development. Almost every country has its own standards. The preceding standards are related to the basic features of boards. Special features must be tailored to meet requirements of different countries. For example, British Telecom (BT) has its own standards, namelyBTNR315. Some of the requirements in the BTNR315 are very special and can be met only by special boards.
Basic Features of the Z Interface

Basic features of the Z interface supported by the voice interface board of the MA5600T/ MA5603T are summarized as follows: l Battery feeding (B) Batter feeding refers to the supply of the voltage and the current to terminals (such as telephones) to ensure the normal operation of terminals. When the telephone is in the on-hook state, the voltage of the MA5600T/MA5603T board is generally 48 V. When the telephone is in the off-hook state, the MA5600T/ MA5603T board supports the constant-current feeding at 20 mA, 25 mA, or 30 mA. The feeding current can be configured according to the actual requirement. The off-hook feeding of the port can be automatically adjusted. If the length of the loop is short, the port is fed with the constant current. If the length of the loop is long, the port automatically adjusts the loop current based on the preset threshold. This design ensures the compliance with the related standards and optimizes the power consumption of the port. If the feeding current is 25 mA and the voltage is -48 V, the feeding current is equal to or larger than 25 mA when the loop resistance is less than 1200 ohm, and the feeding current is larger than 18 mA when the loop resistance is 1800 ohm. MA5600T/MA5603T boards also support the 40-mA feeding current. The 40-mA feeding current increases the power consumption of ports and thus is not recommended.
15 Voice Feature
If the 40-mA feeding current is configured, the number of ports configured with the 40mA feeding current cannot exceed five on each board. l Ringing (R) Ringing refers to the supply of the ring current to telephones so that telephones can ring to inform subscribers of incoming calls. MA5600T/MA5603T boards are designed with the balanced ringing feature. The concept of the balanced ringing is put forward based on the concept of the traditional imbalanced ringing. The traditional imbalanced ringing is classified into two types: (1) In a subscriber line, A line is 0 V and B line is -48 V DC overlaid with the 75 Vrms AC signals. (2) In the subscriber line, A line is -48 V and B line carries the 75 Vrms AC signals. In the case of the balanced ringing, both A and B lines of the subscriber line have the AC signals. The AC signals of the A and B lines are of the same frequency and opposite phases, that is, differential signals. The frequency of signals in the case of the balanced ringing can be set to 16 Hz, 25 Hz, or 50 Hz. The amplitude of the ringing current can reach up to 70 Vrms. The amplitude of the ringing current on a terminal can exceed 35 Vrms if the line impedance is 1400 ohm (5-km lines with the core diameter of 0.4 mm) and the terminal impedance is 4000 ohm. The amplitude of the 50-Vrms ringing current is configurable. This configuration is mainly applicable to the short loop with a length less than one kilometer, aiming to substantially reduce the power consumption of ringing on the ports. The DC offset provided by boards can reach 20 V, which ensures reliable ringing when the distance is long. The break-make ratio of the ringing current can be configured to meet requirements of different carriers in the world. l l Over-voltage protection (O) Over-voltage protection is one of the interface protection measures. Supervision (S) Supervision refers to the detection of telephone state, such as on-hook, off-hook, and offhook in the ringing state. The terminal state can be learned through detection. The terminal state detection is the basis of some calls. l Code/Decode (C) Coding/Decoding refers to the process that analog signals of the subscriber line are converted into digital signals and compressed according to the A/U law. l H - Hybrid circuit Hybrid circuit refers to the conversion from the 2-wire analog interface to the 4-wire digital interface on the board and implementation of the balanced matching with the impedance of the subscriber line. l Test (T) For details about the test function, see Voice Test and Maintenance.
Interface Impedance, Transmission Specifications, and Gain

The voice interface board of the MA5600T/MA5603T supports the configuration of the interface impedance and gain. At present, eight common interface impedances can be configured: l
Issue 01 (2011-10-30)
200+680//100nf (defined by China)

15 Voice Feature
l l l l l l l
200+560//100nf (defined by China) 600 (a common impedance) 150+510//47nf (defined by Russia) 220+820//115nf (widely used in countries like Germany) 220+820//120nf (widely used) 900 (seldom used) 270+750//150nf (widely used and recommended by ETSI)
The interface transmission gain is also configurable. The send gain is generally in the range of +4 dB and -6 dB and the receive gain is in the range of 0 dB to -12 dB. The gain can be configured at the step of 0.5 dB. The transmission specifications of the boards are fully compliant with the ITU-Q522 test requirements. If the interface impedance is not one of the preceding eight types, independent software can be developed to support the interface impedance.
Digit Collection
The voice interface board of the MA5600T/MA5603T supports the pulse-based digit collection. Old-fashioned telephones generally adopt the pulse dialing mode, while new telephones adopt the DTMF dialing mode. Most telephones support the pulse dialing mode. The service boards support the pulse-based digit collection at the speed of 8 pps to 12 pps. The break-make ratio is in the range of 50% and 80%. The interval of pulses is configurable and is in the range of 100 ms and 2 s. The default interval of pulses is 300 ms. The DTMF digit collection is completed by the DSP instead of the service boards.
Charging Signals
Service boards support three charging modes, namely polarity reverse, 12/16KC, and counter impulse delivery. l l l Polarity reverse: The voltage polarity between A and B lines of the subscriber line is reversed. Some terminals detect this type of reverse for charging purpose. 12/16KC: The service board sends the 12000 Hz/16000 Hz sine AC signals at a specific interval to the terminals. Counter impulse delivery: The service board sends pulse signals to the terminals. Charging is implemented based on the pulse signals.
All ports of the service board support both the fast and slow polarity reverse features. Fast polarity reverse is generally completed within 3 ms, which meets the time requirements of polarity reverse of some telephones. Slow polarity reverse is generally completed within 80 ms. It can substantially reduce the interference to the line during the polarity reverse and is compatible with the DSL transmission on the same line. The service board supports the 12/16KC charging. In the 12/16KC charging mode, the amplitude of the 12/16KC signals is configurable. The amplitude can be set to 0.45 Vrms, 0.775 Vrms, 1 Vrms, 1.5 Vrms, 2 Vrms, or 2.5 Vrms. The maximum value is 2.5 Vrms (200 ohm). In addition, the break-make ratio of KC signals is also configurable. By default, the Make duration is 100 ms and the Break duration is 300 ms. Both the Make duration and the Break duration range from 10 ms to 500 ms.
15 Voice Feature
The service board also supports the counter impulse delivery charging. Some attributes of this charging mode, such as the pulse width and number of pulses sent per minute, are configurable.
Current Reduction of Locked Ports

When a phone connected to a port is in off-hook state for a long time but the conversation is not going on, the service board can lower the current of the port to less than 12 mA to reduce the power consumption of the port.
Short Loop Feeding

When the length of the line is short, the service board uses the low voltage for feeding to reduce the power of the port. When the length of the line becomes long, the service board automatically uses the voltage higher than the previous low voltage to meet the application requirement.
Power Cut-off
Feeding of ports that are not allocated with numbers can be cut off to reduce the power consumption of the ports.
On-Hook Transmission
Service boards support the on-hook and off-hook transmission functions, such as the caller identification display service and the fixed network short message service.
Ringer Equivalence Number

Ringer equivalence number (REN) refers to the number of telephones that can be connected to the same port. The MA5600T/MA5603T allows a port to connect to a maximum of four to five telephones.
15.10 Voice Test and Maintenance

The test and maintenance features of voice services include the loop line test, circuit test, call emulation test, continuity test, and Real-time Transport Control Protocol (RTCP) statistics.
15.10.1 Introduction
Definition
The test and maintenance features of voice services include loop line test, circuit test, call emulation test, connectivity test, and RTCP statistics.
Purpose
With these features, the MA5600T/MA5603T can provide various test and maintenance functions.
15.10.2 Loop Line Test and Circuit Test

Line maintenance is important for voice services. When voice service quality problems or call faults occur before or after the service provisioning, the subscriber line needs to be tested at first.
15 Voice Feature
The test helps determine whether the fault is on the subscriber line or the device. The line test features are provided by the MA5600T/MA5603T for this purpose. The loop line test is to test the electrical specifications of the line between the testing device and the telephone of the subscriber. The circuit test is to test the electrical specifications inside the POTS service board. Table 15-11 lists the specific test items. Table 15-11 Test items Test Type Test Item A->G DC voltage B->G DC voltage A->B DC voltage A->G AC voltage B->G AC voltage A->B AC voltage A->G AC frequency B->G AC frequency A->B AC frequency A->ground insulation resistance B->ground insulation resistance Loop line test A->B insulation resistance(low) B->A insulation resistance(low) A->B insulation resistance(high) B->A insulation resistance(high) A->ground capacitance B->ground capacitance A->B capacitance(low) A->B capacitance(high) A->ground conductance B->ground conductance A->B conductance(low) A->B conductance(high) A->ground susceptance
15 Voice Feature
Test Type
Test Item B->ground susceptance A->B susceptance(low) A->B susceptance(high) A->ground DC current B->ground DC current A->B DC current B->A DC current A->ground AC current B->ground AC current A->B AC current B->A AC current Digital voltage Low power supply voltage (negative) High power supply voltage (negative) Positive power supply voltage Off hook detective On hook detective
Circuit test
A->B feeder voltage A->ground feeder voltage B->ground feeder voltage B->A feeder voltage Ringing current voltage Ringing current frequency Stop ringing Loop current
After the loop line test and the circuit test are performed, the device generates a final test conclusion based on the test indexes, and provides a result that indicates the circuit line and loop line are normal or explains the cause of the fault, which assists the maintenance personnel in performing further operations. Table 15-12 and Table 15-13 list the conclusion of the loop line test and circuit test.
Issue 01 (2011-10-30)
598
15 Voice Feature
Table 15-12 Conclusion of the Circuit test Test Type Conclusion Normal Circuit test Abnormal Not support
Table 15-13 Conclusion of the loop line test Test Type Conclusion Items Result Normal A->ground AC voltage is hazardous to persons B->ground AC voltage is hazardous to persons AB->ground AC voltage is hazardous to persons A->ground EMF AC voltage exist B->ground EMF AC voltage exist AB->ground EMF AC voltage exist A->ground abnormal AC voltage exist B->ground abnormal AC voltage exist AB->ground abnormal AC voltage exist Loop line test Line state A->ground DC voltage is hazardous to persons B->ground DC voltage is hazardous to persons AB->ground DC voltage is hazardous to persons A->ground EMF DC voltage exist B->ground EMF DC voltage exist AB->ground EMF DC voltage exist A->ground abnormal DC voltage exist B->ground abnormal DC voltage exist AB->ground abnormal DC voltage exist A line grounding B line grounding AB line grounding
Issue 01 (2011-10-30)
599
15 Voice Feature
Test Type
Conclusion Items
Result A->ground resistance fault B->ground resistance fault AB->ground resistance fault A->ground resistance leak B->ground resistance leak AB->ground resistance leak AB->ground poor insulation AB->ground capacitance leak A->ground capacitance leak B->ground capacitance leak A line break ( For voice line, there is no this result ) B line break ( For voice line, there is no this result ) Double line break or no terminal Cut off in MDF Cut off out MDF Self mixed in MDF Self mixed out MDF PPA not detected A->B PPA detected
PPA test result
B->A PPA detected A->B 2 PPA detected B->A 2 PPA detected Phone not connected Off hook ETSI Signature or Elec ring circuit
Terminal status
A-B short or off hook R-C network ( on hook or modem exist ) Electronic ringing circuit Other terminal
Issue 01 (2011-10-30)
600
15 Voice Feature
The cable deployment and network features vary with the countries or carriers. The MA5600T/ MA5603T supports the setting of the thresholds for the test indexes. The test conclusion in the preceding table is based on the calculation of the thresholds. If the thresholds are not modified by the maintenance personnel, the default values are adopted. The calibration values of the subrack are required for determining whether the cause of fault is broken lines inside the office, broken lines outside the office, self-mixing lines inside the office, or self-mixing lines outside the office. With the calibration values of the subrack, the device automatically obtains the simulated calibration values in case of broken loop line or self-mixing line of the subscriber port, and performs the loop line test. Hence, the device can draw a precise conclusion of broken lines inside the office or self-mixing lines outside the office. The subscriber may be using the telephone service when the loop line test and circuit test are performed. To ensure normal service for subscribers in the case of tests, the MA5600T/ MA5603T provides three options for maintenance personnel: no test on busy, forced test on busy and defer test on busy.
15.10.3 Search Tone

The search tone helps users to pinpoint the subscriber line connected to a specific port. When the device plays the search tone to a specific port, a subscribe line is pinpointed if this line can hear the search tone. Range of the search tone amplitude: 80-500 mV Range of the search tone frequency: 300-3400 Hz
15.10.4 Signal Tone Test

Introduction
The signal tone test is to test whether the signal tone played to users is normal. Table 15-14 Signal tone types Type Busy tone Dial tone Description l Supports two test modes: out-ofservice and in-service. l out-of-service: In this mode, the signal tone test is performed on the MA5600T/MA5603T, independent of the upper-layer device. l in-service: In this mode, the upperlayer device needs to play the signal tone for testing. Ring back tone Special dial tone Supports two test modes: out-of-service and in-service.
Issue 01 (2011-10-30)
601
15 Voice Feature
Restrictions
l l l A signal tone test can be performed on different boards concurrently. A signal tone test can be performed only on one port on a board at a time. A signal tone test cannot be performed concurrently with a search tone test, circuit test, or loop line test on a board at a time.
15.10.5 Call Emulation Test

With the scale deployment of MA5600T/MA5603Ts, the number of MA5600T/MA5603Ts in service increases. In addition, MA5600T/MA5603Ts are deployed near the subscriber premise and may be physically located in complicated or remote environment. Therefore, a remote fault locating method is required for quickly locating the subscriber data or the device fault. Before the service is provisioned to the subscriber, the call emulation test can be performed to emulate the actual service. The function of the call emulation test is to emulate subscriber calls and help the maintenance personnel locate the fault without having to be present on the site. Call emulation includes emulation of the calling party and emulation of the called party. The voice subscriber port on the MA5600T/MA5603T can be emulated as the calling party or the called party, and the test is performed with other manual operations. Emulation of the calling party refers to emulating the subscriber offhook, number dialing, conversation, and onhook on the port. 1. 2. 3. 4. Set one port to the emulated calling party. Configure the number to be dialed in the test, and start the test. Emulate the subscriber offhook on the port. After the dial tone is detected, the emulated phone generates the preset telephone number. On the side of the called party (the number of whom is dialed by the emulated calling party), if the phone ringing tone can be heard, it indicates that the signaling connection is successful. Answer the phone, and if the voice of the maintenance personnel who answers the phone can be heard on the receiver (remote loopback is automatically set by the calling party), it indicates that the media channel is available.
Emulation of the called party refers to emulating the called subscriber on the port. 1. 2. 3. Set one port on the device to the emulated called party. Start the test, and dial the number of the emulated subscriber from any remote phone. Ringing current can be detected on the port of the emulated called party. Emulate an offhook and set remote loopback. If the ring back tone can be heard on the side of the calling party before the offhook, it indicates that the signaling channel is normal. If the voice of the calling party can be heard on the receiver, it indicates that the media channel is available.
15.10.6 RTCP Statistics

Complying with the H.248 protocol, the softswitch, during and at the end of a call, can query the RTCP statistics of a user, including the number of transmitted RTP packets, bytes of transmitted RTP packets, number of received RTP packets, bytes of received RTP packets, number of lost transmitted packets, number of lost received packets, network jitter, and network loop delay.
15 Voice Feature
The MA5600T/MA5603T reports its real-time statistics to the softswitch when the softswitch issues signaling to query the statistics. Then, the softswitch or the OSS system can manage the quality monitoring based on the statistics.
15.10.7 Remote Packet Capture

After an MA5600T/MA5603T runs on the network, remote packet capture is a useful maintenance means. For example, when the quality of the voice service is poor or the fax/modem service easily fails, the original media packets need be captured to locate the fault. The remote packet capture feature of the MA5600T/MA5603T implements the free-of-on-site and fast and timely packet capture according to the fault symptoms. This greatly saves the cost and improves the efficiency of fault location. Figure 15-29 the networking of MA5600T/MA5603T remote packet capture
Capture service
NMS center Bearer network
SR
SR
MA5600T/ MA5603T
MA5600T/ MA5603T
Phone
Fax
Modem
Phone
Fax
Modem
Media packet duplication stream Media stream of normal call
Figure 15-29 shows the networking of MA5600T/MA5603T remote packet capture. The basic principle is as follows: The MA5600T/MA5603T duplicates the media packet of a specified user port, adds the MAC/IP/UDP header into the media packet, and then transmits the media packet to the specified server. On the server, a special tool is used to receive the UDP packet and remove the MAC/IP/UDP header to resume the original data. The duplication of the media packet on the MA5600T/MA5603T is implemented by the DSP chip rather than the CPU of the control board. Therefore, the remote packet capture does not affect the normal voice service or the system. The server for the remote packet capture can be specified or integrated into the N2000 BMS. The server can be a PC or a server dedicated to the packet capture. Therefore, before the remote
15 Voice Feature
packet capture function is enabled, related data of the server such as the IP address need be configured. The remote packet capture function can be enabled as follows: l Specify the user port information, such as subrack/slot/port ID and TID. In this situation, when the specified user initiates a call and starts the conversation, the remote packet capture function is enabled to trace the entire call process. This is applicable to a certain user port where a problem is reported and rarely recurs, or to a certain service (fax/modem) that has problems. l Press button to enable the packet capture function. The application scenario is that when the voice quality is poor during a call, the user can press a certain combination of phone buttons (such as 911*#). After the MA5600T/ MA5603T detects the numbers, the packet capture function is enabled to capture the data timely. The numbers need be pre-set on the MA5600T/MA5603T; otherwise, the packet capture function cannot be enabled. The MA5600T/MA5603T supports up to two channels of packet capture concurrently.
15.10.8 ToolBox
Context
The ToolBox is a signaling tracing tool running on Huawei N2000 BMS as well as a maintenance tool provided by Huawei. It is used to trace the voice signaling of various access products. The signaling traced by the ToolBox includes H.248 signaling, MGCP signaling, IUA signaling, Q.921 signaling, DPNSS signaling, DASS2 signaling, SIP signaling, and Q931 signaling. The MA5600T/MA5603T supports three protocols, namely, MGCP, H.248, and SIP. Therefore, the ToolBox can trace the signaling of these three protocols. The signaling tracing can be used to locate and isolate the call faults. The ToolBox can trace the signaling based on the service port. The following considers the H. 248 signaling as an example for signaling tracing.
Procedure
Step 1 Choose Trace > H248 Message Trace from the main menu. A dialog box is displayed, as shown in Figure 15-30.
Issue 01 (2011-10-30)
604
15 Voice Feature
Figure 15-30 Trace/H248 message trace dialog box
Step 2 In the Location Method pane, select Phone No.. Input the phone number in the Parameter Setting pane, and click OK. A message tracing window is displayed, as shown in Figure 15-31. Figure 15-31 H.248 message trace window
Step 3 In the Location Method pane, select Frame/Slot/Port. Input the frame ID, slot ID and port ID of the port to be traced, and click OK. A message trace window is displayed, as shown in step 2. Step 4 In the Location Method pane, select MGID+TID. Input the MG ID and TID, and click OK. A message trace window is displayed, as shown in step 2. Step 5 In the Location Method pane, select MGID. Input the MG ID, and click OK. A message trace window is displayed, as shown in step 2. Step 6 Double click the desired message, or select the message and then press Enter. The Message Explanation window is displayed.
15 Voice Feature
Step 7 In the message tracing window, right-click, and then: l Select Pause to pause the rolling window to query messages. l Select Continue to make the paused window scroll again. l Select Save. In the dialog box that is displayed, input a file name, and click Save to save the messages in the current window as a .txt file. l Select Clear to clear the messages in the current window. l Select Statistics. In the dialog box that is displayed, select the statistical item and related parameters. Click OK. Then, the message trace classified query window is displayed. Step 8 Close the message trace window to end the trace. ----End
15.10.9 QoS Alarm

The network quality affects the voice service to a great extent. During a call, the MA5600T/ MA5603T monitors the network quality in real time. When the network quality is below the preset threshold, a corresponding alarm is generated on the MA5600T/MA5603T to warn the customer of the network quality. The QoS alarm function is used to monitor three indexes, packet loss, loop delay, and jitter. The corresponding values can be set according to the actual network condition. During a call, the MA5600T/MA5603T collects the data of packet loss, loop delay, and jitter, and then compares the data with the preset thresholds. When the data exceeds the thresholds, an alarm is generated. When the network indexes return to be lower than the preset thresholds, a recovery alarm is generated on the MA5600T/MA5603T. The QoS alarms can detect the network abnormalities in real time. When users complain, the QoS alarm can be referred to locate the fault (whether caused by the network or device).
15.11 Voice Reliability

This topic describes features related to voice reliability, including dual-homing networking, highly reliable transmission (SCTP), and voice QoS.
Definition
Features related to voice reliability include dual-homing networking, highly reliable transmission, and voice QoS.
Purpose
The purpose is to ensure the high reliability of the MA5600T/MA5603T voice service.
15.11.2 Working Principle

15 Voice Feature
15.11.2.1 H.248/MGCP Dual Homing

Dual homing is an NGN (Next Generation Network) total solution. Based on this solution, when the active softswitch or the link from the MG to the active softswitch is faulty, the MG need be switched to the standby softswitch immediately to prevent call services of users connected to the softswitch and the MG from being affected. Dual homing requires that one MG is configured with two softswitches, one active and one standby. The connection between the MG and the softswitch is detected through the heartbeat message. Figure 15-32 illustrates the working principle of dual homing. Figure 15-32 Working principle of dual homing
Active softswitch
MG Standby softswitch Loses communication with active softswitch Register
Reply with success Heartbeat Heartbeat

Reply Resumes communication with active softswitch Deregister Register
Reply with success
Reply with success
1. 2. 3.
The MG detects the interrupted connection between the MG and the active softswitch through the heartbeat message. The MG registers with the standby softswitch. The MG sends the detection messages to the active softswitch at regular intervals (same as common heartbeat intervals), If the MG receives the response from the active softswitch, it indicates that the communication with the active softswitch is recovered. In this case, the MG takes the next action. If receiving no response from the softswitch, the MG keeps sending the detection messages. The MG sends a message to the standby softswitch for service cancellation and waits for the response from the softswitch. After receiving the response from the standby softswitch, the MG starts to register with the active softswitch. If three consecutive attempts of registration fail, the MG registers with the standby softswitch again following the same procedure.
4. 5.
Issue 01 (2011-10-30)
15 Voice Feature
Different carriers may choose the following different dual homing policies: 1. 2. When the original active softswitch recovers, the MG automatically switches to the original active softswitch. The MG does not support the auto-switching. Regardless of whether the MG registers with the active softswitch or the standby softswitch, if the softswitch with which the MG registers is normal, the MG works with this softswitch all along. The MA5600T/MA5603T can support the preceding two policies through related configuration. By default, the MA5600T/MA5603T supports the second policy.
15.11.2.2 H.248 Multi-homing Overview

As an enhancement of dual-homing, multi-homing is a configuration in which a media gateway (MG) is homed to the primary media gateway controller (MGC), secondary MGC, and disasterrecovery MGC. The system supports the following configurable switching policies for multi-homing: 1. Automatic switching back l An MG registering with the secondary MGC will automatically switch back to the primary MGC when the primary MGC recovers. l An MG registering with the disaster-recovery MGC will automatically switch back to the primary/secondary MGC when the primary/secondary recovers. 2. No automatic switching back l An MG registering with the secondary MGC will not automatically switch back to the primary MGC when the primary MGC recovers. l An MG registering with the disaster-recovery MGC will not automatically switch back to the primary/secondary MGC when the primary/secondary MGC recovers.
Network Application
Issue 01 (2011-10-30)
608
15 Voice Feature
Figure 15-33 H.248 multi-homing network

Police office
MSAN
Primary MGC
Secondary MGC
H.248
H.248
H.248 ESA-GW
H.248
ESA-GW
H.248
H.248
ESA-GW ......
ESA-GW
MSAN Emergency Call MSAN Internal Call MSAN<->MSAN Call
Police office
ESA-GW: emergency standalone-gateway
MSAN: multi-service access node
As shown in the preceding figure, an MSAN is an MA5600T/MA5603T and an ESA-GW can be a small-capacity softswitch in network deployment. Generally, ESA-GWs and MA5600T/ MA5603Ts are deployed in the same telecommunications room. When disconnected from the primary and secondary MGCs (for example, due to a fiber cut), the MA5600T/MA5603T initiates registration to the ESA-GW. After the successful registration, all call services of the MA5600T/MA5603T are controlled by the ESA-GW. In this way, the following services are still available even if the MA5600T/MA5603T is disconnected from the primary and secondary MGCs: 1. 2. 3.
Issue 01 (2011-10-30)
Call services of users connected to the same MA5600T/MA5603T Call services of users connected to different MA5600T/MA5603Ts (homed to the same ESA-GW) Emergency call services
15 Voice Feature
Pay attention to the following aspects when applying H.248 multi-homing: 1. 2. The call service capabilities are restricted by the ESA-GW. The callee of an emergency call (for example, police emergency call) must be connected to an MA5600T/MA5603T.
NOTE
This limitation is a supplement to the solution shown in Figure 15-33. Whether such an limitation takes effect depends on the actual core network topology.
3.
Only the POTS users are supported (the ISDN users and other users are not supported).
Switching Process
Figure 15-34 Process of switching to the ESA-GW
Access Node Primary MGC Secondary MGC ESA-GW
Disconnect with Primary MGC
Disconnect with Secondary MGC Clear all calls ServiceChange(Restart,901) Reply Connect with ESA-GW Lopp Check ESA-GW Connection Notify Reply
Loop Check whether the connection has resumed ServiceChange(Restart,901)
Loop Check whether the connection has resumed ServiceChange(Restart,901)
Issue 01 (2011-10-30)
610
15 Voice Feature
Figure 15-35 Process of switching back

Access Node Primary MGC Secondary MGC ESA-GW
Disconnect with primary MGC Disconnect with secondary MGC Connect with ESA-GW The connection with Primary MGC has resumed The connection with Primary and Secondary MGC have resumed ServiceChange (Restart,901) Reply Connect with Primary MGC Stop send ServiceChange to Secondary MGC Clear all calls Out of service from ESA-GW ServiceChange(Forced, 905) Reply
Loop Check the connection with Primary MGC Notify Reply
15.11.2.3 Emergency Standalone

Emergency standalone is a solution in which the users on the same MG can call each other even when the interface between the MG and the softswitch is interrupted. After a user picks up the telephone, the MG (namely, the MA5600T/MA5603T) checks whether the interface connected the softswitch is interrupted. l l If the interface is in the normal state, the normal softswitch process starts. Otherwise, the MG checks whether emergency standalone can be enabled. If yes, the MA5600T/MA5603T controls the call process. If no, the user listens to the sound (because the interface is faulty and emergency standalone is not allowed). Figure 15-36 shows the operating principle of emergency standalone.
Issue 01 (2011-10-30)
611
15 Voice Feature
Figure 15-36 Operating principle of emergency standalone

Softswitch/IMS Softswitch/IMS
Access Node
Access Node
Phone
Phone
Phone
Phone
The emergency standalone process is as follows: l The service processing after the calling party picks up the telephone is as follows: 1. 2. 3. 4. The calling party picks up the telephone. The device automatically delivers the dial tone to the calling party. The calling party dials a phone number. The device analyzes the dialed number and finds out the called party on the same device. The phone number is configured for a user when the user is configured on the MG. The device delivers the ringing signal and calling party's phone number to the called party. The device delivers the ring-back tone to the calling party. The called party picks up the telephone. The device stops delivering the ring-back tone to the calling party. The calling and called parties start a conversation. Any of the two parties puts down the telephone. The device delivers the busy tone to the other party. The other party puts down the telephone.
5. 6. l 1. 2. 3. l 1. 2. 3. l
The service processing after the called party picks up the telephone is as follows:
The service processing after any party puts down the telephone is as follows:
Limitation of emergency standalone: Only the unabbreviated number is supported and the Centrex group, abbreviated number message, user outgoing/incoming call authority, and various new services are not supported. A user can call another user only on the same VAG.
Issue 01 (2011-10-30)
612
15 Voice Feature
The feature applies only to the VoIP user. The dual-homing feature and the emergency standalone feature cannot be enabled at the same time.
15.11.2.4 SIP Dual Homing

Figure 15-37 shows the networking of SIP dual homing. Figure 15-37 Call releasing flow
Server 1 Server 2
IP Core Network
MA5600T/MA5603T
The working flow of SIP dual homing is similar to the working flow of H.248/MGCP dual homing. The MA5600T/MA5603T detects the proxy server in real time. When the primary proxy server is faulty, services can be switched to the secondary proxy server. Before the switching, the call can be released. After the switching, the call can be initiated.
15.11.2.5 H.248/SIP over SCTP

Currently, most devices adopt H.248/SIP over UDP. H.248.4 recommends H.248/SIP over SCTP, which implements the message retransmission at the application layer through SCTP. Compared with the UDP protocol, the SCTP protocol has the following advantages: 1. 2. Reliability: Messages can be transmitted fast and reliably through SCTP. Multi-homing: With the multi-homing feature, multiple IP addresses are supported on an SCTP endpoint. That is, an SCTP endpoint can use multiple physical network ports to enhance the endpoint reliability. Congestion control: The congestion control through SCTP is similar to the congestion control through TCP. Heartbeat mechanism: SCTP provides the heartbeat mechanism at the network layer. Security: Four-way handshake and cookie mechanisms effectively prevent the DoS attack.
3. 4. 5.
Issue 01 (2011-10-30)
S IP
:O
PT IO
NS
NS
:O SI P IO PT
15 Voice Feature
As shown in Figure 15-38, the IP protocol is used at the network layer, SCTP the transport layer, and H.248/SIP the application layer. Figure 15-38 Protocol architecture of H.248/SIP over STCP
MG
MGC
H.248/SIP STCP IP
H.248/SIP STCP IP
15.11.2.6 SIP over TCP

Some carriers require the TCP-based SIP signaling transmission, which implements the packetization of the SIP packet (the SIP packet is large in size) and enhances the transmission reliability through TCP. As shown in Figure 15-39, the IP protocol is used at the network layer, TCP the transport layer, and SIP the application layer. Figure 15-39 Protocol architecture of SIP over TCP
MG
MGC
SIP TCP IP
SIP TCP IP
15.11.2.7 Voice QoS

The voice service requires high real-time performance, low delay, and fast call connection. Therefore, the voice packets should be forwarded with a high priority. The router, however,
15 Voice Feature
forwards the packets based on the VLAN priority (complying with 802.1p) and DSCP/ToS set in the packets.
802.1p Priority (Separately Set for Signaling and Media Streams)

Figure 15-40 802.1q frame format
802.1Q header T P TCI I D 4 bytes
Destnation Address
Source Address
Length /Ty pe
Data
FCS ( CRC-32)
6 bytes
6 bytes
2 bytes
46- 1517 bytes
4 bytes
Byte1
Byte2
Byte3
Byte4
TPID( Tag Protocol Identifier )
TCI( Tag Control Information )

C F i
1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 Priority
VLAN ID
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Figure 15-40 shows the Ethernet frame format defined in 802.1q. The four-byte 802.1q header contains the following contents: l l Tag protocol identifier (TPID): Two-byte tag protocol identifier, with the value of 8100. Tag control information (TCI): Two-byte tag control information. It is a new type of information defined by IEEE, indicating a text added with the 802.1q label. The TCI is divided into the following three fields: VLAN identifier (VLAN ID): 12-bit, indicating the VLAN ID. Up to 4096 VLANs are supported. All the data packets transmitted from the host that supports 802.1q contain this field, indicating the VLAN to which the data packets belong. Canonical format indicator (cfi): one-bit. It is used in the frame for data exchange between the Ethernet network of the bus type and the FDDI or token ring network. Priority: three-bit, indicating the priority of the frame. Up to eight priorities are supported. It determines the data packet to be transmitted first in case of switch congestion. The local media IP address and signaling IP address of the MA5600T/MA5603T can be configured in one VLAN or different VLANs according to the networking requirements. The 802.1p priorities (in the range of 0-7) can be set for the media IP address and signaling IP address respectively. By default, the priority for either the media IP address or the signaling IP address is 6.
15 Voice Feature
DSCP/TOS
As defined in the IP protocol, the DSCP and ToS occupy the same field (one-byte) in the IP header. The device on the IP bearer network identifies whether DSCP or ToS is filled in the IP header, and schedules and forwards the packets with the DSCP/ToS field according to the settings to ensure the QoS for different services. The type of service (ToS) field contains a three-bit precedence subfield (ignored currently), a four-bit ToS sub field, and one reserved bit (it must be set to 0). The four bits in the ToS sub field represent the minimum delay, maximum throughput, maximum reliability, and minimum cost respectively. Only one of the four bits can be set. If all four bits are set to 0, it indicates the common service. The DSCP identification is based on the IPv4 ToS and the IPv6 traffic class. As shown in Figure 15-41, the first six bits in the DS field (bits 0-5) are used to differentiate the DS codepoints (DSCPs) and the last two bits (bits 6 and 7) are reserved. The first three bits in the DS field (bits 0-2) are the class selector codepoint (CSCP), which indicates a class of DSCP. Figure 15-41 DSCP identification format
DS Field
0 1 2 3 4 5 6 7
IPv4 TOS
0 1 2 3 4 5 6 7 unused
DSCP
0
Precedence ToS
CSCP
DSCP is used to select the corresponding per-hop behavior (PHB) on all the nodes of the network. The PHB describes the external visible behaviors when the DS node functions on the data stream aggregation. Currently, IETF defines three types of PHB: expedited forwarding (EF), assured forwarding (AF), and best-effort. For example, l l l BE: DSCP = 000000 EF: DSCP = 101110 The AF codepoints are as follows: Low Discard Priority, j = 1 AF (i = 4) AF (i = 3) AF (i = 2) AF (i = 1) 100010 011010 010010 001010 Middle Discard Priority, j = 2 100100 011100 010100 001100 High Discard Priority, j = 3 100110 011110 010110 001110
Issue 01 (2011-10-30)
616
15 Voice Feature
The first three bits (bits 0-2) for one type of AFs are the same. To be specific, the first three bits of AF1 are 001, AF2 010, AF3 011, and AF4 100. Bits 3-4 represent the discard priority, namely, 01, 10, and 11. The larger the value, the higher the discard priority. The DSCP/ToS value of local media IP packet and signaling IP packet can be configured on the MA5600T/MA5603T respectively. First the configuration policy (DSCP or ToS) is selected, and then the corresponding value is set. By default, DSCP is selected on the MA5600T/ MA5603T, with the value of 56 (EF with the highest priority).
Issue 01 (2011-10-30)
617
16 Device Management Security
16
About This Chapter
16.1 Introduction 16.3 Availability
Device Management Security
This topic covers the overview, general specifications, availability, and sub-features of device management security.
16.2 Relevant Standards and Protocols
16.4 SNMP This topic provides an introduction to the SNMP sub feature, and then describes the working principle of this sub feature. 16.5 Inband Management VPN Inband management VPN is a means by which carriers use the virtual private network (VPN) to manage and maintain devices and the management protocol on the device can use virtual routers for route forwarding. 16.6 SSH This topic provides an introduction to the SSH, and describes the working principle of this sub feature. 16.7 User Management This topic covers the overview and working principle of user management. 16.8 Remote Connection Security This topic provides an introduction to the remote connection security, and describes the working principle of this sub feature. 16.9 Log Management This topic covers the overview and working principle of log management. 16.10 Version and Data Management This topic provides an introduction to the version and data management feature, and describes the working principle of this sub feature. 16.11 Alarm and Event Management This topic covers the overview and working principle of alarm and event management.
Issue 01 (2011-10-30)
619
16.1 Introduction
Device security includes the following features: SNMP, SSH, user management, remote connection security, log management, version and data management, and alarm and event management. Feature SNMP SSH Description The NMS communicates with the device through SNMP. Based on the application layer and transport layer, SSH is a protocol that provides security for remote login session and other network services. It is used for remote management connection and file transfer. User management involves management of user rights and encryption of the user name and password. It includes a series of firewall functions aiming at users' login connection to the device, and the function of disabling the device service port. The security administrator is separated from the system administrator. Only the security administrator can configure the functions related to the device security. Logs include the security event logs relevant to the system security events and the operation logs of users. This management function includes patch management, rollback function, configuration data management, and version upgrade. This management function includes recording and setting alarms and events and collecting their statistics.
User management Remote connection security Independent security administrator Log management Version and data management Alarm and event management

SNMP
The following lists the reference standards and protocols of device security: 1. 2. SNMPv1 l RFC1157: Simple Network Management Protocol (SNMP) SNMPv2c l RFC1905: Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) 3. SNMPv3 l RFC2570: Introduction to Version 3 of the Internet-standard Network Management Framework
l RFC2571: An Architecture for Describing SNMP Management Frameworks l RFC2572: Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) l RFC2573: SNMP Applications l RFC2574: User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) l RFC2575: View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
SSH
Encryption for remote management connection: l l l l RFC4254: The Secure Shell (SSH) Connection Protocol RFC4253: The Secure Shell (SSH) Transport Layer Protocol RFC4252: The Secure Shell (SSH) Authentication Protocol RFC4251: The Secure Shell (SSH) Protocol Architecture
Encryption for file transfer: None
User Name/Password Management

None
Remote Connection Security

None
Log Management
None
Version and Data Management

None
Alarm and Event Management

None
16.3 Availability
Related NEs
The operation and maintenance security of the device is related only to the security management of the device. Therefore, it is related only to the MA5600T/MA5603T and not to any other NE.
License Support
The corresponding service is provided without a license.
Version Support
Feature Dependency
l The password must meet the requirements of the current system.
16.4 SNMP
This topic provides an introduction to the SNMP sub feature, and then describes the working principle of this sub feature.
16.4.1 Introduction
Definition
The Simple Network Management Protocol (SNMP) is a network management protocol that is widely used in the TCP/IP network. It provides a means of managing network resources using a central computer (network management workstation) that runs the network management software. Network management involves four parts: l l l l Managed node: device that is monitored, namely NE. Agent: software used to trace the status of the managed nodes (devices). Network management workstation: central device that communicates with the agents of the managed nodes and displays the status of the agents. Network management protocol: protocol (such as SNMP) for information exchange between the network management workstation and the agent.
Figure 16-1 shows the typical configuration of an SNMP-managed network. The entire network must have at least one network management workstation, which acts as the network management center and runs the manager process. Each managed node must have an agent. The manager and the agent communicate with each other using UDP-based SNMP messages.
Issue 01 (2011-10-30)
622
Figure 16-1 Typical configuration of an SNMP-managed network
Managed node (device) Agent process SNMP UDP Network management workstation Manager process SNMP UDP IP Network interface Managed node (device) Agent process SNMP UDP IP Network interface User process FTP... TCP IP Network interface User process FTP... TCP
Purpose
SNMP is mainly used for network management. There are two types of network management, as described in the following: l l One is management of network applications, user account, and access right (permission). Such management is related to software and is not described in detail. The other is management of NEs such as the MA5600T/MA5603T. Generally, the managed devices are far away from the central telecommunications room where the network management engineers work. When such devices are faulty, it is ideal if the network management engineers are notified of the faults automatically. However, devices such as the MA5600T/MA5603T cannot do the same as users making phone calls to notify the network management engineers of its application faults.
To resolve such an issue, equipment vendors provide network management functions for some devices. In this way, the network management workstation can query the status of managed devices remotely; likewise, the managed devices send alarms to the network management workstation when events of a specific type occur.
The specifications of the SNMP are as follows: l l l
Issue 01 (2011-10-30)
SNMPv1, SNMPv2c, or SNMPv3 server Static registration of the MIB tree Processing of the SNMP get request
l l l l l l l l l l l l l l l l l
Processing of the SNMP get next request Processing of the SNMP set request Community name management and community name check User-based security model (USM) View-based access control model (VACM) Configuring the source address of traps Enabling or disabling the trap transmission Configuring the system group information Counting the SNMP packets Dynamically adding or deleting a MIB subtree Configuring the specifications of SNMP devices Incremental development of the SNMP MIB If the NMS sends the get next message to a module that is performing a CLI operation, the system returns an error and notifies the NMS of the data synchronization failure. SNMP supports the message in a maximum size of 17940 bytes. Modifying the key of the SNMPv3 user Configuring the MIB port of the trap destination host The ID of the SNMP engine can be configured to be generated by sysName. SNMPv3 supports two encryption algorithms, namely, AES and DES.
16.4.3 SNMP Network Management Model

Through the SNMP protocol, signaling is exchanged between the network management workstation and the agent. l l l The manager in the network management workstation sends an SNMP request PDU to the agent. After obtaining the required information following the query of the MIB of managed devices, the agent sends an SNMP response PDU to the manager. When the managed device is abnormal, the agent notifies the manager of the fault through a trap, which helps the network management engineers solve the problems in time.
Figure 16-2 shows the SNMP network management model. Figure 16-2 SNMP network management model
NMS Agent MIB Managed object

Implementation of SNMP network management consists of three parts: management information base (MIB), structure of system management (SMI), and SNMP.
16.4.4 SNMP MIB

The management information base (MIB) is an abstract set of all managed objects. MIB is treestructured and therefore is called the MIB tree. Each managed object corresponds to a leaf in the MIB tree and is called a MIB leaf. The MIB tree is a static tree, that is, the MIB tree structure completes initialization after the device is started. After that, the manager only searches for or modifies the contents of each managed object. The manager manages devices by reading information from and writing information to the managed objects in the MIB.
16.4.5 SNMP SMI

The structure of management information (SMI) defines a set of rules of naming and defining managed objects to achieve communication between SNMP entities. SNMP is a protocol running at the application layer, which requires the protocol entities at the two ends to exchange PDUs. However, data at the lower layer is byte sequence. In this case, SMI is applied to help SNMP protocol entities to change the received byte sequence to a PDU and then change the PDU with the internal data structure to a byte sequence that can be sent.
16.4.6 Working Principle of SNMPv1

SNMPv1 specifies five core protocol data units (PDUs), that is, SNMP messages, which are exchanged between the manager and the agent. l l l l l Get-request: Retrieves the value of one or more parameters from the agent. Get-next-request: Retrieves the value of the next parameter from the agent lexicographically. Set-request: Sets the value of one or more parameters for the agent. Get-response: Returns the value of one or more parameters. This operation is sent by the agent and is a response to the preceding three operations. Trap: PDU sent actively by the agent to notify the manager of the occurrence of certain events. When a device generates an alarm indicating that important data of the device is changed by the user, console, or another manager, the agent notifies the manager of such information through traps. After receiving the traps, the manager generates relevant actions (such as polling) to diagnose faults.
The first three operations are sent from the manager to the agent and the last two from the agent to the manager, as shown in Figure 16-3.
Issue 01 (2011-10-30)
625
Figure 16-3 Exchange of SNMPv1 PDUs

SNMP application SNMP application
MIB
GetNextRequest
GetNextRequest
GetResponse
GetResponse
SetRequest
SetRequest
SNMP PDU Structure

An SNMP PDU consists of the common SNMP header, get/set header, trap header, and variable bindings, as shown in Figure 16-4. Figure 16-4 SNMP PDU structure
IP data packet UDP data packet 20 bytes 8 bytes SNMP PDU Get/Set header Variablebindings
Version PDU type Community (0) (0-3)
GetRequest
GetRequest
SNMP manager UDP IP Physical network
IP Common SNMP UDP header header header
PDU type Enterprise (4)
Trap
SNMP agent UDP IP Physical network
Request Error status Error Name Value Name Value ID (0-5) index
Trap
...
IP address Trap type of the (0-6) agent
Specific- TimeName Value Name Value code stamp Variable-bindings
...
Trap header
Common SNMP header The common SNMP header consists of three fields:
Issue 01 (2011-10-30)
626
Version. The value of this field is the PDU version minus one. For example, the value of this field for the SNMPv1 PDU is 0. Community. It is the password in plain text used between the manager and the agent, in the format of character string. A common community name is public, a string of six characters. PDU type. There are five types of PDU, as listed in Table 16-2. Table 16-2 SNMP PDU type PDU Type 0 1 2 3 4 Name Get-request Get-next-request Get-response Set-request Trap
Get/Set header Request ID It is an integer set by the manager. When sending the get-response PDUs, the agent also needs to return the request ID. The manager can send the get PDUs to multiple agents using the UDP port. However, the response PDU for the first get PDU does not necessarily arrive first. Considering such a situation, the request ID is set so that the manager can correlate incoming response PDUs with corresponding request PDUs. Error status It is filled when the agent responds to the manager, as described in Table 16-3. Table 16-3 Error status PDU Type 0 1 2 3 4 5 Name noError tooBig noSuchName badValue readOnly genErr Description No error occurs. The agent fails to put the response into an SNMP PDU. The operation specifies a non-existent variable. A set operation specifies an invalid value or syntax. The manager is trying to modify a read-only variable. Some other errors occur.
Error index
When an error such as noSuchName, badValue, or readOnly occurs, the agent sets an integer as the error index during its response. The error index specifies the position of the error variable in the variable list. l Trap header Enterprise This field is filled with the object ID of the network device carried in the trap PDU. Trap type The formal name of this field is generic-trap. There are seven trap types, as described in Table 16-4. Table 16-4 Trap type Trap Type 0 1 2 3 4 5 6 Name coldStart warmStart linkDown linkUp authenticationFaliure egpNeighborLoss enterpriseSpecific Description The agent is initialized. The agent is re-initialized. A port changes from the working state to the faulty state. A port changes from the faulty state to the working state. A PDU with an invalid community name is received from the SNMP manager. The MA5600T/MA5603T, an EGP neighbor, is faulty. This field indicates an event defined by the agent, which is specified by the specific-code field.
In the case of 2, 3, or 5, the first variable in the variable-bindings of a PDU needs to specify the port that is used for response. Specific-code This field specifies the event (for example, trap type 6) defined by the agent. If the event is not defined by the agent, this field is filled with 0. Time stamp This field specifies the time elapsed between the initialization of the agent and the generation of the trap, in the unit of 10 ms. For example, if the time stamp is 1908, it indicates that the trap is generated 19080 ms after the initialization of the agent. l Variable-bindings This field specifies the name and value of one or more variables. In the get or get-next PDU, this field is filled with 0.
Issue 01 (2011-10-30)
628
16.4.7 Working Principle of SNMPv2c

Simplicity is a key to SNMP success, which caters to the need of clear management protocols in a large-size and complicated network involving devices of multiple vendors. However, to achieve simplicity, SNMP sacrifices certain functions, for example: l l l l SNMP does not provide the bulk access mechanism, causing low access efficiency of large data. SNMP runs over only TCP/IP. It does not support other network protocols. SNMP does not provide the mechanism for communication between managers. It is applicable to centralized management, but not distributed management. SNMP can be used for monitoring network devices, but not for monitoring the network.
Aiming at resolving these problems, IETF continuously optimizes SNMP and finally formulates SNMPv2c. SNMPv2c has the following enhancements to SNMPv1: l l l Supports new types of PDUs. Extends the types supported by SMI. Supports communication between managers.
New PDU in SNMPv2c

l GetBulk GetBulk is an extension of get-next. That is, a getBulk operation equals multiple get-next operations. With one getBulk operation, a large amount of information can be obtained, which effectively reduces communications between the manager and the agent and thus improves network performance.
16.4.8 Working Principle of SNMPv3

The structure of SNMPv3 is model-based, which facilitates addition and modification of the protocol functions. SNMPv3 has the following advantages: l l l Good adaptability: SNMPv3 is applicable to multiple operation environments. It can manage both simple networks and complicated networks. Excellent scalability: New models can be added according to actual requirements. High security: SNMPv3 provides multiple security processing models.
SNMPv3 has four major models: message processing and control model, local processing model, user-based security model (USM), and view-based access control model (VACM). Different from SNMPv1 and SNMPv2, SNMPv3 implements access control, identity authentication, and encryption through its local processing model and USM.
Message Processing and Control Model

Defined in RFC2272, the message processing and control model is responsible for generating and analyzing SNMP PDUs and determining whether PDUs need to pass the agent server during transmission. During the generation of a PDU, this model receives the PDU from the dispatcher, and then the USM adds the security parameters to the PDU header. When analyzing a received PDU, the USM processes the security parameters in the PDU header and sends the processed PDU to the dispatcher for processing.
Local Processing Model

The local processing model is mainly used for access control. Access control is to set the information about an agent so that different managers in the management workstation have different rights when accessing the agent. It is implemented through the PDU. Access control can be implemented using the following two methods: by limiting the commands that the manager sends to the agent or by determining the information in the MIB of the agent that the manager visits. The access control method must be set beforehand. SNMPv3 can flexibly determine the access control method through the primitives carrying different parameters.
USM
The USM provides identity authentication and data encryption services. To implement such functions, the manager and the agent must share the same key. l Identity authentication: When receiving a message, the agent (manager) must determine whether the message is sent from the authorized manager (agent) and whether the message is changed during transmission. This is called identity authentication. RFC2104 defines HMAC, which is an effective tool of generating message authentication codes using cryptographic hash functions and keys. It is widely applied in the Internet. HMAC used by SNMP are HMAC-MD5-96 and HMACSHA-96. HMAC-MD5-96 adopts the MD5 hash function, with the 128-bit authKey as its input. HMACSHA-96 adopts the SHA-1 hash function, with the 160-bit authKey as its input. Encryption: It adopts CBC-DES, with the 128-bit privKey as its input. The manager uses a key to calculate the authentication code and then adds the authentication code to the message. After receiving the message, the agent uses the same key to obtain the authentication code and thus decrypts the message. Similar to identity authentication, encryption also requires that the manager and the agent share the same key for message encryption and decryption.
VACM
The VACM implements view-based access control over user groups or community names. A user must first configure a view with rights specified. Then, the user loads the view when configuring a user, user group, or community name so that the read operation, write operation, or traps (v3) can be limited.
16.4.9 Comparison Between SNMP Protocols in Security

Table 16-5 describes the comparison between SNMP protocols in security. Table 16-5 Comparison between SNMP protocols in security SNMP Version v1 v2c User Authentication No; use the community name. No; use the community name. Encryption No No Authorization No No
Issue 01 (2011-10-30)
630
SNMP Version v3
User Authentication Yes; encryption/ decryption based on the user name.
Encryption Yes
Authorization Yes
SNMPv3 USM
SNMPv1 and SNMPv2c lack a security mechanism. SNMPv3 supports the user-based security model (USM) against illegal modification of information and masquerade. USM mainly checks whether the SNMP message is modified during the network transmission and whether the SNMP message is sent by the alleged user, monitors the outdated SNMP message, and provides the privacy mechanism for SNMP messages. USM consists of three modules: l l l Authentication module: Authenticates the data origin. Timeliness module: Prevents message delay or replay. Privacy module: Prevents message disclosure.
SNMPv3 VACM
The access control subsystem of the SNMP engine checks whether an access to a special object is allowed. View-based access control model (VACM) is a default access control model in SNMPv3. Compared with SNMPv1 and SNMPv2c, SNMPv3 adopts a more rigorous and dynamic access control model, which facilitates configuration by network management engineers. VACM consists of the following parts: l Groups A group is a set of zero or multiple mappings. It defines all the access rights to all securityNames that belongs to the group. Security level. Different access rights are defined by different security levels. l Contexts An SNMP context is a collection of management information accessible by an SNMP entity. l l MIB views and view families Access policy Read-view Write-view Notify-view
16.5 Inband Management VPN

Inband management VPN is a means by which carriers use the virtual private network (VPN) to manage and maintain devices and the management protocol on the device can use virtual routers for route forwarding.
Issue 01 (2011-10-30)
631
16.5.1 Introduction
Definition
In inband management VPN, associated inband management protocols on the device support the specified VPN instances so that management packets can be received and forwarded using multiple virtual routes. In this way, carriers can use the private network IP address to remotely manage and maintain devices. This method saves public network IP addresses and isolates the management network from the public network. To achieve inband management VPN, both the inband management server and client must be able to receive the connection requests and data packets from VPN.
Constraints
l The outband management interface belongs to the public network but not VPN. Therefore, only the inband interface but not the outband management interface supports VPN management. The servers that can receive VPN requests include: Telnet server SSH server TL1 Telnet server TL1 SSH server SNMP AGENT (currently, only IPv4 but not IPv6 is supported) DBWIN server TRACE server l The clients that can receive VPN requests include: FTP client TFTP client SFTP client SNMP TRAP SYSLOG Telnet client
16.5.2 Principles
Basic Concepts
Virtual private network (VPN) is a network technology for encapsulating or encrypting private data and then transmitting the data over the public network. With this technology, the security level of the private network can be provided for the transmitted data and a private network can be constructed based on the public network. VPN is a logical private network that provides the functions of the private network. The network itself, however, is not an independent physical network. In the IP bearer network, VPN is an important measure for logically isolating services, preventing attacks, and helping implement QoS control. A VPN instance is also called a VPN routing and forwarding table (VRF). Each router is logically divided into multiple virtual routers, that is, multiple VRFs. Each VRF corresponds to a VPN
and has its own routing table, forwarding table, and interface. In other words, a router shared by various VPNs is simulated as multiple private routers, thereby isolating VPN routes. Devices that are grouped into a private route exchange routing information of only the private route.
Inband Management VPN

Inband management VPN uses the VRF function to add the remote NMS and the OLT to the same VPN while on the OLT classifying the management address and VoIP address to different VRFs. In this way, carriers can use the private network IP address to remotely manage and maintain devices. This method saves public network IP addresses and isolates the management network from the public network. Figure 16-5 Network diagram of inband management VPN
VoIP VRF1 Internet ONT VRF2 OLT IPTV
Layer 2/Layer 3 switch IP Network BRAS
NMS
VPN inband management channel VPN service channel
In Figure 16-5, two VRFs (VRF1 and VRF2) are defined on the OLT. VRF2 is the VoIP service channel and VRF1 is the VPN inband management channel. On the OLT, if a system-level VPN instance for management and maintenance is configured, all related management protocols by default use this VPN instance to connect to or send data to the remote server. In addition, if a user specifies the VPN instance of a single server when configuring the trap destination server or running the telnet command, these two management protocols (for trap and telnet) do not use the system-level VPN instance but instead use the specified VPN instance to connect to the remote server.
16.6 SSH
This topic provides an introduction to the SSH, and describes the working principle of this sub feature.
16.6.1 Introduction
Definition
Secure Shell (SSH) is formulated by the IETF Network Working Group. Based on the application layer and transport layer, SSH provides security for remote login session and other network services.
Purpose
Conventional network service programs such as FTP and telnet transmit password and data in plain text over the network. Unlike these conventional programs, SSH encrypts data to be
transferred, which effectively avoids information divulge during remote management. In addition, during SSH encryption, data is compressed to a smaller size, which helps achieve faster data transfer.
The specifications of the remote management connection encryption are as follows: l l l l SSH 1.x and SSH 2.0 RADIUS authentication for the user's login through SSH User password authentication, user public key authentication, user password+public key authentication, user password or public key authentication. AES, DES, 3DES, and BLOWFISH encryption algorithms for login through SSH
16.6.3 SSH Working Principle

The SSH protocol involves the server and the client. l As a service daemon, the server responds to connection requests from the client and processes remote connections, including shared key authentication, key exchange, asymmetric encryption, and non-secure connection. The client contains the SSH program and applications such as slogin and SFTP. In terms of the client, SSH provides the following two levels of security authentication. One is password-based security authentication. Users can log in to a remote device as long as they know the user name and password for login. In this authentication mode, all data to be transferred is encrypted, but the server to which users are connecting is not always the desired server. That is, maybe some other server pretends to be the desired one. The other is key-based security authentication. In this authentication mode, a pair of keys (server key and host key) need to be created, and the server key needs to be put into the desired server. If a client needs to connect to an SSH server, the client sends a request to the server for security authentication using the host key. Upon receiving the request, the server compares its saved server key with the host key sent by the client. If the two keys are identical, the server sends a "challenge" message encrypted with the server key to the client. After receiving the "challenge" message, the client decrypts the message using the host key and then sends the message back to the server. Till now, the client passes the authentication. As a security protocol, SSH provides only secure channels but does not transfer data. Through the steps including version negotiation, key exchange, algorithm negotiation, and user authentication, an SSH secure channel is set up. Any data transfer protocol can transfer data in the channel. The tool used by the secure maintenance terminal provides the SSH client function. Figure 16-6 shows the interaction process between the client and the server using SSH.
Issue 01 (2011-10-30)
634
Figure 16-6 Interaction process using SSH

Client Connection establishment Server version string Client version string Key exchange User authentication Provide the SSH service Connection cut-off Server
16.6.4 SSH-based Encryption for Remote Management Connection

The system supports management of remote operations in the outband or inband telnet mode. l The port used by outband telnet is the only Ethernet port (RJ-45) on the front panel of the control board. After configuring the IP address and related routes of this port, users can log in to the device through telnet for related operation, maintenance, and management. The port used by inband telnet is the VLAN interface of the device. The system supports a maximum of 32 IP addresses for the VLAN interfaces and the subnets of these IP addresses must be different.
In implementing remote operations, both the secure maintenance terminal and the common maintenance terminal transfer data through telnet. The difference is that the secure maintenance terminal, before transferring data through telnet, encrypts data using SSH. With SSH-based encryption, all the operations are secure after the user logs in to the device through a remote terminal for maintenance and management.
16.6.5 SSH-based Encryption for File Transfer

SFTP is an SSH-based secure file transfer protocol. When a user is authenticated in the password mode, both the user name and password are required on the client. If the user name and password cannot be obtained, file transfer fails. Figure 16-7 shows the process of file transfer through SFTP.
Issue 01 (2011-10-30)
635
Figure 16-7 Process of file transfer through SFTP

Client Server
SSH initialization phase SFTP version authentication phase
SFTP file open phase
SFTP file read/write phase SSH connection cut-off phase
The process of uploading a file through SFTP is as follows: 1. 2. 3. The client opens the local file that needs to be uploaded to the server. The client sends a request to the server for opening the file on the server. The client writes the local data to the server according to the returned file handle.
Downloading a file through SFTP is based on the SSH authentication: 1. 2. 3. 4. The server and the client both verify the SFTP version in the SFTP stage. The client opens the local file and the remote file. The client reads the corresponding data. The client closes the opened files after reading the data.
16.7 User Management

This topic covers the overview and working principle of user management.
Issue 01 (2011-10-30)
636
16.7.1 Introduction
Definition
User management involves the following two parts: l l A user needs to be authenticated with user name and password when the user attempts to log in to the device through the command line interface (CLI). Users are classified into four levels, namely, super user, administrator, operator, and user. Different levels of users are assigned different operation rights.
Purpose
User management is to ensure the security of device management and maintenance by user name +password authentication and hierarchical right-based management.
The specifications of the user name/password management are as follows: l l l l l l l l Separation and unification of the security administrator and the system administrator Binding a user profile to a user. The user profile defines the valid period for the user name and password, and the time range when the user is permitted to log in. Operation users are divided into four levels by rights: super users, administrators, operators, and common users. The length of the character string of the user name and password: 6-15 characters. The password must contain at least one character and one digit. Automatic lockout of the user name if it is idle for a long time The idle time is configurable. Lockout of the user name and password if the valid period expires The valid period of the user name and password is configurable. Lockout of the user name if the number of login attempt failures of the user name exceeds N. N is configurable. By default, it is six. l Lockout of the user with an IP address if the number of login attempt failures from this IP address exceeds N. N is configurable. By default, it is six.
16.7.3 Principle
When a user logs in to the system through the CLI, the user must enter the user name and password for authentication. In this way, the user is authenticated to ensure the system security. Users are classified into four levels, namely, super user, administrator, operator, and user. Different levels of users are assigned different operation rights. The super user and the administrator have the right to add a user at a lower level, that is: l l The super user can add an administrator, operator, or user. The administrator can add only an operator or user.
Issue 01 (2011-10-30)
637
The system also supports management of user profiles. A user profile supports setting of the following parameters: l l l l l l Minimum length of a user name (6-15 characters) Minimum length of a password (6-15 characters) Validity period of a user name (0-999 days) Validity period of a password (0-999 days) Start time of user login in the format of hh:mm (for example, 08:30) End time of user login in the format of hh:mm (for example, 18:30)
If the validity period of the user name or password is set to 0, it indicates that there is no restriction on the validity period of the user name or password. It is also true for the start time and end time of user login. If other values are set, the user login time is restricted based on the preset values. The system reminds the user through a message three days before the user name and password expire. After the preceding settings, the security of system management is enhanced to a certain extent. When created, if a user is bound to a user profile and the start time of user login in the user profile is set to 08:30, it indicates that the user cannot log in to the system before 08:30. After a user profile is set, the user profile can be directly bound to a user when adding the user. In addition, the user profile bound to the user that is already created can be modified. A user supports a maximum of 12 user profiles. The system provides four default user profiles named root, admin, operator, and commonuser, which helps manage and create users in a unified way. Different names of user profiles indicate the differences in the preceding security settings for the user profiles rather than the differences in user levels. The user level is specified when a user is added. In a root profile, restrictions on users are disabled so that the user bound to the profile can log in to the system after upgrade. It is not recommended that this profile be bound when adding a user.
16.8 Remote Connection Security

This topic provides an introduction to the remote connection security, and describes the working principle of this sub feature.
16.8.1 Introduction
Definition
With the remote connection security feature, the IP firewall, or the service port of the system is disabled to prevent the device from being attacked by illegal users or illegal operations.
Purpose
IP firewall or disabling the service port can prevent the device from being attacked by malicious users to ensure the security of the device.
The specifications of remote connection security are as follows:
l l l l l
Enabling or disabling telnet, SSH, and SNMPv3 by the IP firewall Configuring the acceptable IP address segments through telnet, SSH, or SNMPv3 by the IP firewall; up to 10 acceptable IP address segments Configuring the refused IP address segments through telnet, SSH, or SNMPv3 by the IP firewall; up to 10 refused IP address segments Disabling the service port (dBWin/Telnet/trace/Telnet proxy/msg-emulate/ntp/radius/ dhcp-relay) that is enabled in the system by default Configuring the number of sessions for remote login through the CLI (including telnet, SSH, and local serial port), ranging from 1 to 20
16.8.3 Principle
With the IP firewall function, only the operators from valid IP address segments are allowed to log in to the device through valid access protocols, and the operators from invalid IP address segments or through invalid access protocols are not allowed to log in to the device. With the function of disabling the system service, the default service monitoring port of the system can be disabled to prevent the port from malicious scanning or attack.
16.9 Log Management

This topic covers the overview and working principle of log management.
16.9.1 Introduction
Definition
Logs can be classified into security event logs and operation logs. l A security event log is a log recorded by the system after a security event occurs. Currently, three types of security events are supported, that is, online/offline event of maintenance users, user lockout event, and auto-backup success event. An operation log is a log about the user operation recorded by the system. It records user login and logout information and other operations performed on the system.
Generally, logs are queried through the CLI, syslog, or backup log file during troubleshooting. Operation logs and security event logs are reported to the NMS.
Purpose
Logs recorded help users obtain the overall system maintenance information for timely troubleshooting.
16.9.2 Principle
Operation Log
The system records commands of successfully issued configurations from the CLI or SNMP interface, that is, operation logs. Operation logs record both successful and failed operations. In logs of failed operations, the operation results can also be recorded.
By default, the system supports a maximum of 512 operation logs, which are saved in the order of time and are overwritten cyclically. After system restart, logs recorded are not lost.
Security Event Log

Events are reminders to the user during the system running. The event attributes include the event ID, event name, event type, event class, event level, and the default event level, where the event level can be customized. When the level of a security event is changed, whether the event is recorded may be changed. A security event is recorded in the log only when its level is minor or higher.
Log Server
Logs can be reported to the log server using syslog in real time. Also, logs can be transmitted to the file server through TFTP/FTP/SFTP at a specified time or when the specified capacity is reached after the automatic uploading conditions are configured. Integrity of logs must be ensured.
NMS Log Management

NMS log management involves management of NMS security logs, NMS operation logs, and NE security logs. By querying and saving logs periodically, network management engineers can detect unauthorized logins or operations and analyze faults in time. Through the logs, the information about the client from which the NMS user logs in to the NMS server and the operations performed after login can be obtained. Also, log data can be dumped or printed.
16.10 Version and Data Management

This topic provides an introduction to the version and data management feature, and describes the working principle of this sub feature.
Definition
Version and data management includes patch management, rollback function, configuration data management, and version upgrade.
Purpose
This sub feature facilitates carriers in version upgrade and maintenance.
Benefits
Benefits to carriers: The carriers' operating expenditure (OPEX) is saved considerably, and the customer satisfaction is increased.
The MA5600T/MA5603T supports the following specifications of the version and data management feature, as listed in Table 16-6.
Table 16-6 Specifications of the version and data management feature SN 1 2 3 4 5 6 7 8 9 10 11 12 Specification Description 100 patches Hot patches, SPH ( Service Package of Hot patches), cold patches and SPC (Service Package of Cold patches). Loading, activating, running, rolling back or deleting a patch Rolling back the program, database, and extended BIOS automatically in case of upgrade failure Rolling back the system manually Canceling the rollback function automatically 48 hours after upgrade success by default Setting the time for canceling the rollback function automatically (5 minutes to 30 days) Saving the configuration data automatically after any changes to the configuration data Saving the configuration data manually Saving the configuration data at a preset time or interval Backing up the configuration data manually or automatically to a specified server Restoring the configuration data to the default settings
16.10.3 Principle
Patch Management
The flash memory (storage medium in the system) has a patch area to store the loaded patches. A patch can be a hot patch or cold patch. The system needs to be restarted for a cold patch to take effect or stop functioning. Nevertheless, in the case of a hot patch, the system need not be restarted for the same purpose. A hot patch supports the rollback function; therefore, the hot patch can be rolled back to the status before the latest hot patch is loaded. In addition, a patch can be activated, deactivated, run, or deleted. The loaded patch is deactivated by default; therefore, to make the loaded patch take effect, activate it. To make the patch take effect after the system restart, activate and run the patch before the system is restarted. The system supports the following four types of patches: l l HP refers to the host hot patch. It takes effect after being loaded and then activated. For a user, this type of patches, after being loaded, is displayed as HPXXX. SPH is the set of HP patches. It takes effect after being loaded and activated. For a user, this type of patches, after being loaded, is displayed as SPHXXX, without displaying the status of HP patches
Issue 01 (2011-10-30)
l l
CP refers to the host cold patch. It takes effect after it is loaded and the system is restarted. For a user, this type of patches, after being loaded, is displayed as CPXXX. SPC is the set of CP patches. It takes effect after being loaded and activated. For a user, this type of patches, after being loaded, is displayed as SPCXXX, without displaying the status of CP patches.
Rollback Function
The flash memory of the control board is divided into two same storage areas (namely, active storage area and standby storage area) to store the program, database, and extended BIOS. The storage area that is operating currently is the active storage area. When the program, database, and extended BIOS are upgraded, the new program, database, and extended BIOS are loaded to the standby storage area. After the system is restarted, the system automatically loads the new program, database, and extended BIOS. The rollback function is implemented based on two sets of program, database, and extended BIOS in both the active and standby storage areas. By default, after upgrade, the system saves the pre-upgrade host program and database for 48 hours. 48 hours later, the system automatically cancels the rollback function. That is, 48 hours later, the system duplicates the program, database, and extended BIOS in the operating area to the standby storage area. In this way, the versions in both the active and standby storage areas are the same. You can set the time for canceling the rollback function to 5 minutes to 30 days. The system supports automatic rollback and manual rollback. After version upgrade, if the system fails to start up, the system is automatically rolled back to the version before upgrade. After version upgrade, if the system becomes abnormal during the running and cannot recover, you can run the rollback command to roll back the system to the version before upgrade.
Configuration Data Management

l Saving the configuration data manually: The current configuration data can be saved manually through the commands. If the configuration data is not saved before the system is reset or restarted, it will be lost after the system reset or restart. Therefore, manually save the configuration data once before the system is reset or restarted. Saving the configuration data after any changes to the configuration data: After the configuration data is changed, the system will save the changed configuration data automatically at a preset interval. This interval is user-defined and ranges from 10 minutes to 10080 minutes (default value: 30minutes). Saving the configuration data at a preset time or interval: In the system, the configuration data can be saved automatically at a preset time or interval. This time or interval is userdefined. For example, the time or interval can be set to 23:00 or two hours respectively. In this case, the configuration data is saved at an interval of two hours or at 23:00.
The data erasure operation can be performed to restore the configuration data of the device to the default settings. The system also supports backing up the current configuration data manually or at a preset time to a specified file server.
Version Upgrade
Software version in the system can be upgraded through the CLI or the NMS by using FTP/ TFTP/XMODEM/STFP.
16.11 Alarm and Event Management

This topic covers the overview and working principle of alarm and event management.
Definition
Alarm and event management mainly involves recording and setting alarms and events and collecting their statistics.
Purpose
Alarm and event management facilitates carriers in performing routine maintenance on the device, locating device faults, and restoring the services provided for users quickly after the services become abnormal.
The MA5600T/MA5603T supports the following specifications of alarm and event management. SN 1 2 3 4 5 6 7 8 9 Specification Description Alarms and events of four severity levels: critical, major, minor, and warning Storing 1000 history alarms and 800 history events Backing up the history alarms and history events automatically to a file server Clearing the active alarms in the current system Adjusting the severity level of an alarm or event Jitter-proof function of an alarm or event Collecting the statistics of the alarms and events Correlation function of the alarms and events Filtering the alarms or events
16.11.3 Principle
The alarm and event management refers to recording and setting the alarms and events and collecting statistics of the alarms and events. The maintenance engineers maintain the device through the alarm and event management so that the device works effectively. After an alarm or event is generated, the system broadcasts the alarm or event to the terminals, mainly including the Network Management System (NMS) and Command Line Interface (CLI) terminals. Currently, the system supports storing 1000 history alarms and 800 history events.
The severity level of an alarm or event can be critical, major, minor, or warning. Although an alarm or event has a default severity level, this severity level can be adjusted according to actual conditions. The contents of an alarm or event include name, parameters (including subrack, slot, and port information), description, possible causes, and handling suggestions. When an alarm is generated, the system implements the jitter-proof function of the alarm to prevent the misreporting of the alarm. To be specific, the alarm is reported only after a specified period expires after the alarm status changes (the specified period ranges from 1s to 60s and is 10s by default). If the alarm status recovers within the specified period, the alarm is not reported. The alarm statistics function is used to collect the statistics of alarms within a specified period. This helps to locate system faults. Alarm correlation refers to associating related alarms. When alarms are in the parent-child relations, the system automatically filters related child alarms if the parent alarm is generated. With the alarm and event filtering function, the user can configure the filtering conditions so that the system reports only the alarms and events that pass the filtering. In this way, the user can concentrate on the important and specified alarms and events. The alarms and events can be filtered according to their ID, severity level, and type.

Glossary USM Description In the SNMP protocol, a user-based security model (USM) is defined to implement the security sub-systems. The USM operates at the message level. It adopts the DES CBC encryption and HMAC authentication, and supports the timeliness functions to simulate the delay and replay attacks. In addition, the USM provides the key management capability to provide functions of key localization and key update.
Acronym/ Abbreviation AES CLI DES MIB SSH SNMP
Full Spelling Advanced Encryption Standard Command Line Interface Data Encryption Standard Management Information Base The Secure Shell Simple Network Management Protocol
Issue 01 (2011-10-30)
644
17 Network Security
17
About This Chapter
17.1 Introduction 17.2 Availability
Network Security
This topic covers the overview, availability, and sub-features of network security.
17.3 Anti-DoS Attack This topic provides an introduction to the anti-DoS attack feature, and describes the working principle of this feature. 17.4 Anti-ICMP/IP Attack This topic provides an introduction to the anti-ICMP/IP attack feature, and describes the working principle of this feature. 17.5 Source Route Filtering This topic provides an introduction to the source route filtering feature, and describes the working principle of this feature. 17.6 MAC Address Filtering This topic provides an introduction to the MAC address filtering feature, and describes the working principle of this feature. 17.7 Firewall Blacklist This topic provides an introduction to the firewall blacklist feature, and describes the working principle of this feature. 17.8 Configuration of Acceptable or Refused Address Segments This topic provides an introduction to the feature of configuring acceptable or refused address segments, and describes the working principle of this feature. 17.9 Service Overload Control This topic provides the definition, purpose, and principle of service overload control. 17.10 Acronyms and Abbreviations
Issue 01 (2011-10-30)
645
17 Network Security
17.1 Introduction
Sub-feature Anti-DoS attack Anti-ICMP/IP attack Source route filtering MAC address filtering Firewall blacklist Firewall Configuration of acceptable/refused address segments Description Indicates the defensive measures taken by the system to control and limit the number of protocol packets sent from a user. Indicates that the system discards malicious ICMP and IP packets sent from a user. Indicates that the system filters the IP packets with the route option sent from a user. Indicates that the system filters the user packets according to the source MAC address or destination MAC address. Indicates that the system filters the service packets whose source IP addresses are in the blacklist. Indicates that the system filters the packets according to the access control list (ACL). Indicates that the system supports configuring acceptable/ refused IP address segments for the firewall of a specified protocol type.
17.2 Availability
Related NEs
The operation and maintenance security of the device is related to mainly the security management of the device, which does not involve the other NEs.
License Support
The operation and maintenance security features of the device are provided without a license.
Feature Dependency
l l When a port on the OPGD board (or the SPUA, ETHA, ETHB board) serves as a subtending port, anti-DoS attack does not take effect on the port. The ICMP/IP packets are filtered by the host CPU. Therefore, if a large number of ICMP/ IP packets are sent to the CPU, the CPU usage will be overhigh. In this case, the anti-DoS attack function can be enabled as a countermeasure. After the anti-ICMP/IP attack function is enabled, the user cannot ping the Layer 3 interface of the device and cannot log in to the device through telnet. There is no impact on the system performance because the MAC address is filtered by hardware.
l l
Issue 01 (2011-10-30)
17 Network Security
The MAC address filtering feature and the anti-MAC spoofing feature can be enabled at the same time. When they are enabled at the same time, the MAC address filtering feature takes priority over the anti-MAC spoofing feature. The firewall blacklist feature is used to check the source IP addresses of packets or match the ACL rule. This has no impact on the system performance. You can use the ACL rule when enabling the firewall blacklist. When both the ACL rule and firewall blacklist are used, the priority of the ACL rule is higher than that of the firewall blacklist. There is no impact on the system performance because the MAC address is filtered by hardware. When adding an address segment, ensure that the start IP address of the address segment is different from that of existing address segments. If the IP address of a user exists in the refused IP address segments, the user is forbidden to log in to the system. Therefore, you need to configure acceptable IP address segments for login in advance.
l l
l l l
17.3 Anti-DoS Attack

This topic provides an introduction to the anti-DoS attack feature, and describes the working principle of this feature.
17.3.1 Introduction
Definition
The denial of service (DoS) attack refers to an attack from a malicious user who sends a large number of protocol packets, which results in denying service requests of normal users by the system. The anti-DoS attack feature refers to the defensive measures taken by the system to control and limit the number of protocol packets sent from a user.
Purpose
The DoS attack affects the running of the system. That is, the system may fail to process the service requests of normal users, or even the system may be crashed. To protect the system, the number of protocol packets received by the system is restricted to a specified range. If the number of protocol packets exceeds the specified range, the packets are discarded as invalid packets and the user who sends these packets is added to the blacklist to deny the packets from the user. The system administrator can force a user in the blacklist to go offline.
Benefits
Benefits to carriers: With the anti-DoS feature, the user who initiates the DoS attack is added to the blacklist. In this way, the carriers' networks are protected. Benefits to subscribers: Subscribers can enjoy stable and safe services because the security of services provided for subscribers is enhanced.
17 Network Security
The specifications of this feature are as follows: l l l l l The anti-DoS attack feature can be enabled or disabled (disabled by default). The number of IP addresses in the blacklist supported by the system is the number of user ports supported by the system. An alarm is generated when a DoS attack occurs and a recovery alarm is generated when a DoS attack disappears. The processing policy of protocol packets can be configured in case of DoS attacks. When the anti-DoS attack function is enabled, the system supports configuration of the rate threshold at which protocol packets are allowed to be sent to the CPU.
17.3.3 Principle
The working principle of the anti-DoS attack is as follows: 1. The system maintains a DoS blacklist. The system administrator can take measures to manually force the user in the DoS blacklist to go offline (for example, deactivating the port). After the anti-DoS attack function is enabled, check whether the DoS attack occurs or stops as follows: l The system monitors the number of protocol packets that each user port sends to the CPU. If the number of protocol packets exceeds the average number of the packets for normal services, the system considers that the DoS attack occurs on this user port. l When the DoS attack occurs on a user port, the system adds the user port to the blacklist. In this case, a policy can be configured for allowing or forbidding protocol packets to be sent to the CPU. l After no DoS attack from the blacklisted user port is detected within a specified period, the system deletes the blacklisted user port from the blacklist. In this way, the protocol packets on the user port are allowed to be sent to the CPU again.
2.
17.4 Anti-ICMP/IP Attack

This topic provides an introduction to the anti-ICMP/IP attack feature, and describes the working principle of this feature.
17.4.1 Introduction
Definition
The ICMP/IP attack means that a malicious user sends ICMP packets or IP packets whose destination IP address is the system IP address. These packets affect the running of the system. The anti-ICMP/IP attack feature means that the system discards malicious ICMP and IP packets sent from a user.
Purpose
The destination IP address of the packets sent by normal users is not the system IP address. The malicious users, however, may send the ICMP or IP packets whose destination IP address is the
17 Network Security
system IP address to attack the system. The ICMP/IP attack can be regarded as one type of DoS attack. If a malicious user sends a large number of ICMP messages (such as ping messages) and IP packets to a certain access system and keeps requesting the response at a short interval, the access system is overloaded and thus cannot process legal tasks. The anti-ICMP/IP attack feature can identify and discard the ICMP or IP packets whose destination IP address is the system IP address, thus protecting the system.
17.4.2 Principle
If an access user sends the access devices the ICMP/IP packets whose destination IP address is the system IP address, the ICMP/IP packets are discarded.
17.5 Source Route Filtering

This topic provides an introduction to the source route filtering feature, and describes the working principle of this feature.
17.5.1 Introduction
Definition
The IP packets with the source route option specify the transmission path of the packets. For example, to configure an IP packet to pass three routers R1, R2, and R3, the interface addresses of the three routers can be specified in the source route option. In this way, this IP packet passes R1, R2, and finally R3, regardless of the route tables on the three routers During the transmission of these IP packets with the source route option, the source address and destination addresses keep changing. Therefore, by properly setting the source route option, the attacker can forge certain legal IP addresses to access the network. The source route filtering feature is to filter the IP packets that are sent by the user and contain the route option field.
Purpose
This feature is used to identify and discard the IP packets with the source route option, and also to protect the carrier networks from being attacked by the forged IP packets.
17.5.2 Principle
After the source route filtering function is enabled on the MA5600T/MA5603T, the MA5600T/ MA5603T discards the IP packets with source route option sent from the access user.
17.6 MAC Address Filtering

This topic provides an introduction to the MAC address filtering feature, and describes the working principle of this feature.
Issue 01 (2011-10-30)
649
17 Network Security
17.6.1 Introduction
Definition
MAC address filtering is to filter the user packets according to the source MAC address or destination MAC address of the user packets.
Purpose
This feature, which supports configuring the user packets without the source MAC address or destination MAC address, is mainly to prevent the carriers' networks from being attacked by a malicious user who forges the legal MAC address.
The specifications of this feature are as follows: l l Up to four source MAC addresses can be filtered. Up to four destination MAC addresses can be filtered.
17.6.3 Principle
The MAC address filtering function mainly filters packets according to the source IP address and the destination MAC address, and its working principle is as follows: 1. 2. The MAC address of the network-side device can be set to the source MAC address to be filtered to prevent the user from forging the MAC address of the network-side device. When the user packets are sent upstream, the system checks the source MAC address of the packets. When detecting that the source MAC address of the packets is the same as the configured MAC address of the network-side device, the system discards the packets. The MAC address of the network-side device can be set to the destination MAC address to be filtered to prevent the user from attacking the network-side device.
3.
17.7 Firewall Blacklist

This topic provides an introduction to the firewall blacklist feature, and describes the working principle of this feature.
17.7.1 Introduction
Definition
A firewall blacklist is an IP address set. With the firewall blacklist, the system filters all service packets, whose source IP addresses are listed in the firewall blacklist, to enhance the system security and network security.
Purpose
The firewall blacklist feature is to shield IP addresses that are used by malicious users to attack the system by setting the blacklist.
17 Network Security
Benefits
Benefits to carriers: Carriers can set the blacklist to shield IP addresses that are used by malicious users to attack the system.
The specifications of this feature are as follows: l l Up to 1024 IP addresses can be manually configured in the firewall blacklist. When the blacklist is configured, the valid time (aging time) of the IP address can be specified in the range of 1-1000 minutes. If the aging time is not specified, the IP address never ages.
17.7.3 Principle
The working principle of the firewall blacklist feature is described as follows: 1. 2. If the source IP address of a user packet exists in the firewall blacklist, the user packet is discarded. If packets match the ACL rule, but the IP address of the packets is rejected in the ACL rule, the packets are discarded. If the IP address of the packets is allowed to pass through in the ACL rule, regardless of whether the IP address of the packets exists in the blacklist, the packets can pass the firewall.
17.8 Configuration of Acceptable or Refused Address Segments

This topic provides an introduction to the feature of configuring acceptable or refused address segments, and describes the working principle of this feature.
17.8.1 Introduction
Definition
This feature is to configure acceptable or refused IP address segments for login through the firewall of a specified protocol type.
Purpose
The system supports configuring acceptable or refused IP address segments for login through the firewall of a specified protocol type. This prevents the users of illegal IP address segments from logging in to the system, and maintains the system security.
Benefits
Benefits to carriers: This feature prevents the users of illegal IP address segments from logging into the system and maintains the system security.
17 Network Security
The specifications of this feature are as follows: l l l l l The login to the system through Telnet, SSH and SNMP is supported. For each protocol type, the configuration of acceptable/refused address segments is supported. Each type of firewall can be configured with 10 acceptable IP address segments and 10 refused IP address segments. The acceptable address segment can be configured for IP packets of the telnet, SSH, or SNMP protocol type. Up to 10 acceptable IP address segments can be configured, and the packets whose source IP address is not within the range of the acceptable IP addresses cannot access the system. The refused IP address segment has a higher priority. That is, if an IP address is in both the acceptable IP address segment and the refused IP address segment, the IP address is not allowed to access the system.
17.8.3 Principle
When a user logs in to the system through telnet, SSH, or SNMP, the system checks whether the IP address of the user is within the acceptable IP address segments to determine whether to allow the user to log in to the system. 1. 2. If the IP address of the user is within the acceptable IP address segment, the user is allowed to log in to the system. If the IP address of the user is out of the acceptable IP address segment, the user is not allowed to log in to the system.
NOTE
The refused IP address segment has a higher priority. That is, if an IP address is in both the acceptable IP address segment and the refused IP address segment, the IP address is not allowed to access the system.
17.9 Service Overload Control

This topic provides the definition, purpose, and principle of service overload control.
17.9.1 Introduction
Definition
Overload control (OLC) is a mechanism that prevents exhaustion of system resource such as CPU resources. It protects equipment from service interruption or NMS unreachability triggered by overload of CPU or other resources in the event of heavy traffic. OLC also ensures to a certain extent the quality of high priority services (such as emergency calls) when the system is overloaded.
Purpose
On the live network, the CPU usage or service resources on the access equipment may be overloaded in any of the following conditions: l
Issue 01 (2011-10-30)
Protocol packet flooding

17 Network Security
l l l
Alarm packet flooding Burst traffic due to a large number of concurrent online users Frequent data loading, query, or save operations in the system
The MA5600T/MA5603T provides the OLC feature to ensure that the system is able to successfully process services in any of the above-mentioned conditions.
Benefits
Benefits to carriers The OLC-enabled MA5600T/MA5603T is able to filter and control the packets sent to the CPU to defend the system against malicious attacks and instantaneous service overload, improving device security and reliability.
17.9.2 Availability
License Support
The OLC feature is the basic feature of the MA5600T/MA5603T. Therefore, the corresponding service is provided without a license.
Version Support
17.9.3 Principle
The packets sent to the CPU must be specified with priorities. The packets include internal management packets, network topology management packets, and service (voice and broadband services) packets. The system may have the following packets: l l l l l Internal management packets, including inter-board handshake packets, upper-layer protocol packets, and packets of loading tasks Link-layer network management packets such as MSTP and LACP packets Protocol packets such as routing protocol, BFD, and ETH OAM packets SNMP, ANCP, Telnet, and NTP packets VoIP, IPTV, and private line service packets
The priorities of service packets are planned by carriers; the priority of internal management packets is by default the highest (priority 7); the priorities of other packets are mapped to queues. To meet the requirements of different users, the system supports priority setting on a protocol basis. By default, the system sets priorities on a traffic stream basis.
17 Network Security
To differentiate packets with different priorities, the OLC feature must support different priorities for different queues. It employs the weighted round robin (WRR), strict priority (SP), and leaky bucket algorithms for queue scheduling. Huawei has developed the OLC feature to address the CPU overload issue with the access equipment running on the live network. Figure 17-1 shows the OLC implementation model and Table 17-2 describes the mappings between queues, scheduling algorithms, and packets. Figure 17-1 OLC implementation model on the MA5600T/MA5603T
Leaky bucket algorithm Leak rate control algorithm

Leak rate
Token obtaining (leak rate)
WRR WRR WRR WRR
WRR WRR WRR
WRR
WRR
SP
SP
SP
Board configuration recovery
MIB operations
Loading & saving operations
Queue 15
Queue 16
Queue 13
Queue 14
Queue 17
Table 17-2 Mappings between queues, scheduling algorithms, and packets Queue/ Task Queue 17 Queue 16 Scheduling Algorithm SP SP Packet Type Voice protocol and management packets, such as SIP, H. 248, and MGCP packets l Inter-board communication packets, communication packets between the active and standby control boards, and xPON alarm packets l Packets of automatic loading tasks and Telnet/SNMP/ FTP/TFTP/SFTP packets Queue 15 Queue 14 SP WRR and leaky bucket LACP, MSTP, RRPP, and Smart Link packets RIP, OSPF, IS-IS, LDP, RSVP, BGP, and BFD notification packets about abnormal connections
Queue 0
Queue 2
Queue 1
Queue 3
...
...
Packet priority analysis
Issue 01 (2011-10-30)
654
17 Network Security
Queue/ Task Queues 13 and 12 Queues 11 and 10 Queue 9 Queue 8
Scheduling Algorithm WRR and leaky bucket WRR and leaky bucket WRR and leaky bucket WRR and leaky bucket
Packet Type PPPoE packets DHCP packets BPDU packets and ping packets Network-side IGMP/MLD query packets, and IGMP packets (transmitted over service channels, not VP channels) reported by boards running distributed multicast service Other IGMP/MLD packets except those in queue 8 PIM packets Network-side ARP/ND packets that match network routes Other ARP/ND packets except those in queue 5 Common service packets. Packets enter different queues (queue ID = CoS priority/2) according to their CoS priorities.
Queue 7 Queue 6 Queue 5 Queue 4 Queues 3-0
WRR and leaky bucket WRR and leaky bucket WRR and leaky bucket WRR and leaky bucket WRR and leaky bucket
System manageme nt task
WRR and leaky bucket
l Tasks for loading data, saving data, and synchronizing device data on the NMS l Task for synchronizing data between the active and standby control boards l Task for restoring board configurations l Task for processing xPON alarms and traps l Task for MIB operations
When implementing WRR scheduling, the system also determines whether to read packets from the current queue according to the overload status of the leaky bucket. The system employs different algorithms to schedule packets sent to the CPU: employs SP for queues of management packets and VoIP packets, employs leaky bucket for queues of voice packets (the leak rate is dynamically assigned based on the CPU usage), and employs WRR for other queues. In summary, the system uses different algorithms (leaky bucket, WRR, and SP) to schedule packets in case of system overload so that: 1. Different services in the same queue can be fairly processed to ensure that the burst of a certain type of service packets does not affect other types of service packets.
Issue 01 (2011-10-30)
17 Network Security
2.
The non-protocol packets are controlled by the system-level OLC feature to ensure task fairness and provide basic guarantee for services such as upgrade and user dialup.
WRR
Queues 0-14 in Table 17-2 are scheduled using the WRR algorithm. Figure 17-2 illustrates the principle of the WRR algorithm. Figure 17-2 WRR algorithm
Packets sent from the port Queue Queue 4
Classification
Weight 50 30 10 10 Out-of-queue scheduling
Packets leaving the port
Queue 3 Queue 2 Queue 1
Packet priorities in descending order from left to right
In the WRR algorithm, a weight value is assigned to each queue based on round robin (RR) and a counter is maintained for each queue. During each RR, queues whose counter value is not zero are allowed to send a packet. The initial value of the counter is the weight of a queue. Each time a packet is sent, one is subtracted from the counter value regardless of whether the packet is successfully scheduled or not. When the counter values of all the queues become zero, the counter values are reset to their initial values. The WRR algorithm achieves fairness among queues and smoothly schedules outbound services.
SP
Management packets, voice packets, and important broadband protocol packets are scheduled using the SP algorithm. Figure 17-3 illustrates the principle of the SP algorithm. Figure 17-3 SP algorithm
Queue Packets sent from the port
Classification
Priority
Highest Second highest
Queue 8 Queue 7
Packets leaving the port

Out-of-queue scheduling
Queue 2 Queue 1
Packet priorities in descending order from left or right
In SP queue scheduling, packets are sent in descending order of queue priorities. When a queue with the highest priority is empty, the packets in the queue with the second highest priority are sent. In this way, packets for critical services in a queue with a higher priority are sent first, and
...
Second lowest Lowest
17 Network Security
packets of non-critical services (such as email service) in a queue with a lower priority are sent only when the network is idle and the critical services have been processed.
Leaky Bucket
The MA5600T/MA5603T provides two buckets: a token bucket and a leaky bucket. The system assigns a certain number (a) of tokens to the token bucket every second. The number a is determined by the system processing capability assuming that the CPU usage is 80%. The leaky bucket is designed as a counter. Each time the leaky bucket receives a packet, the leaky bucket applies to the token bucket for a token. When the token is obtained, the count value in the leaky bucket increases by 1 and, at the same time, this count value decreases at the speed of a per second. If a packet arrives when the tokens in the token bucket are used up, the packet will be dropped or marked. The leaky bucket has two control parameters: leak rate (a per second, a equaling the number of tokens in the token bucket) and capacity (N). In the OLC feature design, the leak rate is dynamically adjusted according to the CPU usage. When the CPU usage is higher than the preset CPU threshold, the leak rate is lowered to slow down the arrival rate of packets. When the CPU usage is lower than the preset CPU threshold, the leak rate is raised to speed up packet processing. The capacity (N) remains unchanged regardless of the CPU usage changes. Figure 17-4 illustrates the principle of the leaky bucket algorithm. Figure 17-4 Leaky bucket algorithm
Assign tokens Token bucket Weight water level T2: Water level threshold at 90% CPU usage Leaky bucket T1: control target at 80% CPU usage Current water level in the system
l l
Threshold1 (T1) is the target (level-1) CPU usage threshold (default: 80%). When the CPU usage exceeds 80%, the system starts lowering the leak rate. Threshold2 (T2) is the level-2 CPU usage threshold (default: 90%). When the CPU usage exceeds 90%, the system lowers the leak rate at a faster pace.
The leaky bucket algorithm involves the following key parameters: l Leaky bucket threshold (N): default system capacity (default: 1000; unit: packet). This threshold indicates the standard packet processing capability of the system assuming that the CPU usage is 100%. The value range of N cannot be modified. Target CPU usage threshold (T1): upper limit of the CPU usage (range: 70%-99%; default: 80%). The corresponding water level N1 equals N times T1. Level-2 CPU usage threshold (T2): threshold (range: 71%-100%; default: 90%) of the system resources allowable for traffic of various services when the current water level of the system exceeds N1. The corresponding water level N2 equals N times T2. Adjustment factor (S): adjustment step (range: 1-1000; default: 10). The smaller the adjustment factor, the quicker the upshift or downshift of the leak rate, and the larger the leak rate jitter. Reversely, the slower the upshift or downshift of the leak rate, the smaller the leak rate jitter.
l l
Issue 01 (2011-10-30)
657
17 Network Security
17.10 Acronyms and Abbreviations

Acronym/ Abbreviation ACL DoS ICMP MAC SSH SNMP RR WRR SP OLC Full Spelling Access Control List Denial of Service Internet Control Message Protocol Media Access Control The Secure Shell Simple Network Management Protocol round robin weighted round robin strict priority overload control
Issue 01 (2011-10-30)
658
18 Application Security
18
About This Chapter
18.1 Introduction 18.2 Relevant Standards and Protocols 18.3 Availability
Application Security
This topic provides general specifications, availability, and sub-features of the application security.
18.4 HWTACACS HWTACACS is a security protocol with enhanced functions based on TACACS (RFC1492). Similar to the RADIUS protocol, HWTACACS implements AAA functions for multiple subscribers by communicating with the HWTACACS server in the client/server (C/S) mode. This topic provides the introduction, principle, and reference of the HWTACACS feature. 18.5 RAIO This topic provides an introduction to the RAIO protocol and describes the working principle of this feature. 18.6 PITP This topic provides an introduction to PITP, including the PITP P mode and PITP V mode, and describes the working principle of PITP. 18.7 DHCP option82 DHCP option82 is similar to PPPoE+ as a user security mechanism. The information on a user's access location is added into the DHCP request packets initiated by a user for user authentication. This topic provides introduction to this feature and describes the principle and reference documents of this feature. 18.8 802.1X IEEE 802.1X (hereinafter referred to as 802.1X) is a port-based network access control protocol. 18.9 Anti MAC Spoofing This topic provides an introduction to the anti MAC spoofing feature and describes the working principle of this feature. 18.10 Anti-IP Spoofing
This topic covers the definition and principle of the anti-IP spoofing feature. 18.11 User Isolation This topic provides an introduction to the user isolation feature and describes the working principle of this feature. 18.12 Line Security of the GPON System 18.13 Glossary, Acronyms, and Abbreviations
Issue 01 (2011-10-30)
660
18.1 Introduction
User security refers to the security mechanism that ensures the security of access users, including the HWTACACS, RAIO, PITP, DHCP option 82, 802.1x, anti-MAC spoofing, anti-IP spoofing, and user isolation features. Feature HWTACACS Description Similar to the RADIUS protocol, the MA5600T/MA5603T implements AAA functions for multiple users by communicating with the HWTACACS server in the client/server mode. Relay agent information option (RAIO) is the user physical location information provided by the device to the BRAS or DHCP server, such as the subrack ID, slot ID, and port ID on the device, when PITP and DHCP option 82 are enabled. Policy information transfer protocol (PITP) is a protocol for implementing policy information transfer between the access device and the BRAS through Layer 2 P2P communication. Add the user physical location information in the option 82 field of the DHCP request packet initiated by the user to co-work with the upperlayer authentication server to perform user authentication. 802.1x is a port-based network access control protocol. Users connected to a port can access network resources through the port only after they pass the authentication. The system guards against the attack from users who forge MAC addresses. The system guards against the attack from users who forge IP addresses. The users in different MUX VLANs, or the users in one smart VLAN cannot communicate with each other. Thus, user isolation is implemented at different layers. It is about the line security feature in PON access modes.
RAIO
PITP
DHCP option 82
802.1x
Anti-MAC spoofing Anti-IP spoofing User isolation
Line security

PITP
TR101
802.1X
IEEE Std 802.1X-2001: Port-Based Network Access Control
Issue 01 (2011-10-30)
661
RAIO
TR101
Anti MAC Spoofing

None
Anti IP Spoofing
None
User Isolation
None
Line Security
Line security of the GPON system (AES128 encryption mechanism) l T-REC-G.Imp984.3-200602-E
18.3 Availability
Related NEs
l PITP is used with RAIO, and the cooperation between the MA5600T/MA5603T and the BRAS (or RADIUS server) is required. Table 18-1 lists the requirements for these NEs.
Table 18-1 PITP requirements for NEs MA5600T/MA5603T BRAS RADIUS Server
DHCP option 82 is used with RAIO and the cooperation between the MA5600T/ MA5603T and the DHCP relay agent (or DHCP server) is required.
Table 18-2 DHCP option 82 requirements for NEs MA5600T/MA5603T DHCP Relay Agent or DHCP Server
l l
In general, RAIO is used with PITP or DHCP option 82. The anti-MAC spoofing, anti-IP spoofing, and user isolation features are related to only the MA5600T/MA5603T, and are not related to any other NE.
Issue 01 (2011-10-30)
The line security feature of a PON system requires cooperation between the OLT (configured with PON boards) and the ONU. Table 18-3 lists the requirements for these NEs.
Table 18-3 PON line security requirements for NEs ONU (MDU or ONT) OLT
License Support
l l l l l l l l l HWTACACS is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service. RAIO is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service. PITP is an optional feature of the MA5600T/MA5603T. The corresponding service is controlled by the license. The 802.1x access authentication feature is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service. DHCP option 82 is an optional feature of the MA5600T/MA5603T. The corresponding service is controlled by the license. Anti-MAC spoofing is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service. Anti-IP spoofing is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service. User isolation (MUX VLAN and smart VLAN) is a basic feature of the MA5600T/ MA5603T. Therefore, no license is required to access the corresponding service. Line security is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service.
Feature Dependency
l l l l l Either PITP P mode or PITP V mode can be enabled at a time in the system. That is, PITP P mode and PITP V mode cannot be enabled at a time. A known Ethernet protocol type cannot be set as the protocol type of the PITP V mode. Otherwise, conflict occurs. The user physical location information provided to the BRAS is determined by the RAIO working mode. The MUX VLAN and the smart VLAN can co-exist in the system. When a port on the OPGD board serves as a subtending port, anti-MAC spoofing and antiIP spoofing does not take effect on the port.
Miscellaneous
l The user port must support PITP and DHCP option 82; however, PITP and DHCP option 82 are applicable to any access mode.
Issue 01 (2011-10-30)
RAIO is used with PITP and DHCP option 82, providing the format of the user physical location information for PITP and DHCP option 82.
18.4 HWTACACS
HWTACACS is a security protocol with enhanced functions based on TACACS (RFC1492). Similar to the RADIUS protocol, HWTACACS implements AAA functions for multiple subscribers by communicating with the HWTACACS server in the client/server (C/S) mode. This topic provides the introduction, principle, and reference of the HWTACACS feature.
18.4.1 Introduction
Definition
HWTACACS is a security protocol enhanced based on TACACS (RFC1492). Similar to the RADIUS protocol, HWTACACS implements AAA functions for multiple users by communicating with the HWTACACS server in the client/server (C/S) mode. AAA is short for authentication, authorization, and accounting. It provides the following three functions for users: l l l Authentication: To authenticate the access right of the users and determine which users can access the network. Authorization: To authorize the users to access certain services. Accounting: To keep a network resource usage record of the users.
Purpose
HWTACACS is used for the authentication, authorization, and accounting of the 802.1x access users and administrators.
The MA5600T/MA5603T supports the following HWTACACS specifications: l l l l l l l l l l l
Issue 01 (2011-10-30)
Authentication, authorization, and accounting through HWTACACS for login users Encrypted communication through HWTACACS Configuring the source address of the HWTACACS packet sent from the device Delay recovery for the active HWTACACS server Configuring the response timeout time for the HWTACACS server Configuring the subscriber traffic unit that is reported to the HWTACACS server Configuring whether to carry the domain name in the user name reported to the HWTACACS server Collecting the statistics of the HWTACACS packets Querying the configuration of the HWTACACS server Re-transmitting the stop-accounting packet to prevent the accounting errors caused by the loss of the stop-accounting packet Supports all authority levels issued by the HWTACACS server.
l l l
Supports HWTACACS server grouping. Switches to local authentication when the HWTACACS server returns an authentication packet error. Reports the user IP address when a user enters login authentication.
NOTE
By default, a user is performed with the RADIUS or TACACS authentication for login to a device. A local authentication is performed only when the RADIUS or TACACS server is unreachable. f the RADIUS or TACACS server is reachable, none of the users, except the root user, can log in to the device through local authentication.
18.4.3 Principle
AAA
1. Authentication The MA5600T/MA5603T supports three authentication modes: non-authentication, local authentication, and remote authentication. l Non-authentication: The MA5600T/MA5603T trusts users and does not check the validity of the users. Generally, this mode is not adopted. l Local authentication: The user information (including the user name, password, and various attributes) is configured on the MA5600T/MA5603T, and the MA5600T/ MA5603T authenticates the user. This authentication mode is fast and can reduce carrier's cost; however, the amount of information that can be stored is limited by the device hardware. l Remote authentication: The user information (including the user name, password, and various attributes of the user) is configured on an authentication server. The Remote Authentication Dial In User Service (RADIUS) protocol or HUAWEI Terminal Access Controller Access Control System (HWTACACS) protocol is used for remote authentication. The MA5600T/MA5603T serves as the authentication client and communicates with the RADIUS or HWTACACS server. When the RADIUS or HWTACACS server is faulty, the MA5600T/MA5603T can automatically switch to local authentication. 2. Authorization The MA5600T/MA5603T supports direct authorization, local authorization, HWTACACS authorization, and if-authenticated authorization. l Direct authorization: If trustful, a user can directly pass the authorization. l Local authorization: A user is locally authorized according to relevant attributes of the user configured on the MA5600T/MA5603T. l HWTACACS authorization: The HWTACACS server authorizes a user. l If-authenticated authorization: If a user passes the authentication and the authentication mode is not non-authentication, the user passes the authorization. 3. Accounting The MA5600T/MA5603T supports non-accounting and remote accounting. l Non-accounting: A user is not charged. l Remote accounting: The MA5600T/MA5603T supports remote accounting through the AAA server.
Message Flow of the RADIUS Protocol

The RADIUS server stores the user names and passwords in a unique user database for authenticating the users. When a user wishes to connect to an NE through a device and then obtain the right to access the Internet or access certain network resources, the NE authenticates the user or the corresponding connection. The NE sends the authentication, authorization, and accounting information of the user to the RADIUS server. The RADIUS protocol specifies how the NE and the RADIUS server should exchange the user information and the accounting information. The RADIUS server receives the connection request of the user, authenticates the user, and sends the necessary configuration information of the user to the NE. The exchange of authentication information between the NE and the RADIUS server is key protected. This protects the user password against any interception when the password is transmitted over an insecure network. Figure 18-1 shows the message flow between the RADIUS client and the RADIUS server. Figure 18-1 Message flow between the RADIUS client and the RADIUS server
1. User name password 2. Request 3. Response User NE RADIUS Server
NOTE
An NE refers to an access device that can function as a RADIUS client.
1. 2. 3.
When a user logs in to the NE, the user name and password are sent to the NE. The RADIUS client on the NE receives the user name and password, and sends an authentication request to the RADIUS server. The RADIUS server receives the legal request, authenticates the user, and sends the necessary authorization information of the user to the RADIUS client.
The authentication information exchanged between the RADIUS client and the RADIUS server must be encrypted before being transmitted over the network. Otherwise, the information may be intercepted when the network is insecure. The accounting message flow is similar to the authentication/authorization message flow.
Differences Between HWTACACS and RADIUS

The HWTACACS message flow is similar to the RADIUS message flow. The difference is that, in the HWTACACS message flow, the server returns an authentication response rather than the user right after the user passes authentication. The user right is returned only when the authorization process is completed. HWTACACS features more reliable transmission and encryption than RADIUS and is more suitable for security control. Table 18-4 lists the main differences between HWTACACS and RADIUS.
Table 18-4 Differences between HWTACACS and RADIUS HWTACACS Uses TCP to implement more reliable network transmission. Encrypts the entire body of the packet except the standard HWTACACS packet header. Separates authorization from authentication. Suitable for security control. RADIUS Uses UDP. Encrypts only the password field in the authentication packet. Performs authentication and authorization together. Suitable for accounting.
18.5 RAIO
This topic provides an introduction to the RAIO protocol and describes the working principle of this feature.
18.5.1 Introduction
Definition
The Relay Agent Information Option (RAIO) is used for the device to provide the physical information of a user, such as the subracks, slots, and ports on the device, to the BRAS or DHCP server when the PITP and DHCP Option82 functions are enabled. In addition, the physical information is contained in the following packets for transmission: l l l PITP response packets (PITP V mode) Discovery packets (PITP P mode) DHCP packets (DHCP Option82)
Purpose
Through the RAIO, the device provides the physical location information of a user to the BRAS or DHCP server. In addition, the RAIO is used with PITP and DHCP Option82 to ensure the security of the user account.
Benefits
For the carrier: The RAIO provides the carrier with flexible and customized features, which facilitates proper network planning. For users: The RAIO authenticates the binding relation between the physical information of a user and the user account. This prevents theft of the password of the user account.
Issue 01 (2011-10-30)
667
The RAIO mainly includes the PITP tag and DHCP option 82 tag and is not standardized currently. Therefore, different carriers may put forward different RAIO formats. To meet the requirements of different carriers, multiple RAIO working modes are supported. Global config mode and RAIO profile mode are supported. The following lists the RAIO working modes: l l l l l l l l l l l l l l l common xdsl-port-rate cntel cntel-xpon ti neuf port-userlabe service-port-userlabel dslforum-default brt user-defined ft tm bbf dslforum-default
18.5.3 Principle
Working Principle of the Common Mode
The CID format is usually used to identify the attribute information (global information) about the device. The CID format varies with the access mode. Table 18-5 lists the CID formats of different access modes. Table 18-5 CID formats of different access modes Access Mode ATM port VDSL/LAN access mode xPON CID Format Device name atm shelf ID/slot ID/subslot ID/port ID: vpi.vci Device name eth shelf ID/slot ID/subslot ID/port ID: vlanid Device name xpon shelf ID/slot ID/subslot ID/port ID: gemport.ontid.vlanid
When the device name field is the default "MA5600T/MA5603T", fill the field with the MAC address of the device, and the format is "00E0FC000001", with the uppercase letters.
Issue 01 (2011-10-30)
When the device name is not "MA5600T/MA5603T", fill the device name field with the actual name of the device.
The RID format is usually used to identify the access information (local information) of a user. Generally, the RID format is user-defined. In the case of the MA5600T/MA5603T, the RID format is null. That is, the RID format contains only the Code and Len fields, but does not contain the Value field. An example of an RAIO filed in the common mode is as follows: l l CID ----> 00E0FC112233 atm 0/12/0/49:0.35 RID ----> Null
Working Principle of the xDSL Port Rate Mode

In this mode, this field for upstream/downstream ADSL activation rate is added at the end of the CID default format. Currently, only the ADSL2+ board supports this mode. The RAIO field in this mode is as follows: "AccessNodeIdentifier {atm|eth} frame/slot/subslot/port[:vpi.vci|vlan]%Up:xxxkbps Dowm:xxxkbps" l l l l %: Information identifier, which indicates the information after is the activation rate. XXX: Indicates the ADSL activation rate in the unit of kbit/s. Up: Indicates the upstream activation rate. Down: Indicates the downstream activation rate.
The following is an example of RAIO field in xDSL port rate mode: l l CID ----> 00E0FC112233 atm 0/12/0/49:0.35%Up:1020kbps Down:24540kbps RID ----> NULL
Working Principle of the Port-userlabel Mode

In the port-userlabel mode, the CID carries the information required by the common mode and the label of the service port (that is, the user-defined port description that has a maximum length of 32 bytes). The RID format must also carry the label of the port. An example of an RAIO filed in the port-userlabel mode is as follows: l l CID ----> 00E0FC112233 atm 0/12/0/49:0.35 075528978944 RID ----> 075528978944
Working Principle of the Service-port-userlabel Mode

The CID supports the ATM/ETH/xPON access. The RID carries the description of the traffic stream of the user. Table 18-6 shows the detailed format of the RAIO field.
Issue 01 (2011-10-30)
669
Table 18-6 RAIO field in the service-port-userlabel mode Field CID Access Mode ATM ETH CID Format <Access-Node-Identifier> atm slot/port: vpi.vci VLAN-based multiple services: <Access-Node-Identifier> eth slot/port: flowpara Other: <Access-Node-Identifier> eth slot/port: vlanid xPON VLAN-based multiple services: <Access-Node-Identifier> xpon frame/slot/0/port: gemport.ontid.flowpara Other: <Access-Node-Identifier> xpon frame/slot/0/port: gemport.ontid.vlanid RID description-of-flow-label (description of the traffic stream)
Working Principle of the Dslforum-default Mode

The Dslforum-default mode is the default mode of the DSL forum. The CID supports the ATM/ ETH/xPON access and the RID is null. Table 18-7 shows the detailed format of the RAIO field. Table 18-7 RAIO field in the Dslforum-default mode Field CID Access Mode ATM ETH CID Format <Access-Node-Identifier> atm slot/port: vpi.vci VLAN-based multiple services: <Access-Node-Identifier> eth slot/port: flowpara Other: <Access-Node-Identifier> eth slot/port: vlanid xPON VLAN-based multiple services: <Access-Node-Identifier> xpon frame/slot/0/port: gemport.ontid.flowpara Other: <Access-Node-Identifier> xpon frame/slot/0/port: gemport.ontid.vlanid
Working Principle of the BBF Mode

The Broad Band Forum (BBF) complies with the TR-156 standard. The CID supports ATM/ ETH access and the RID varies with the application scenario. Table 18-8 shows the detailed format of the RAIO field.
Issue 01 (2011-10-30)
670
Table 18-8 RAIO field in the BBF mode Networ k DSLAM Field CID Access Mode ATM ETH RID FTTx CID ATM ETH RID Format <Access-Node-Identifier> atm slot/port:vpi.vci <Access-Node-Identifier> eth slot/port:[vlan-id] Null <Access-Node-Identifier> atm slot/port/ONUID/slot/ port:vpi.vci <Access-Node-Identifier> eth slot/port/ONUID/slot/ port:[vlan-id] ONT label
NOTE
When a user packet carries a user-side VLAN tag, vlan-id is the user-side VLAN ID. Otherwise, there is no vlan-id.
Working Principle of the User-defined Mode

This mode allows users to specify the format of the CID/RID character string. The following section describes the syntax rules of the user-defined mode. l The user-defined mode supports the parse of only the defined keyword set or separator set in the system. The keyword set include the minimum set of keywords defined by TR-101 and the keyword set of the IAS extension, as shown in Table 18-9. Maximum width The maximum width is the maximum number of columns occupied by the keyword data (the maximum widths of certain keywords defined in the system exceed the standard value mainly because the requirements of certain vendors have exceeded the standard maximum width). The maximum width of the keyword ANID is restricted by the maximum character string length of system names (currently, a maximum of 50 characters is supported). l Configurable width If the width is configurable, the number of columns occupied by the keyword data can be configured. When the number of columns is smaller than the configured width, 0 is added. The syntax is keyword 0m, where m is the number of occupied columns. For example: slot03 indicates that the field length of the slot is 3 and 0 is added in front of it when the length is shorter than 3. Slot 2 is 002 in the packet. The value of m cannot exceed the maximum width. The actual data is output if the number of columns occupied by the data is greater than m.
Issue 01 (2011-10-30)
671
Table 18-9 User-defined keywords Keyword Description Whether configura ble width No No No No No Yes Yes Yes Yes Yes Yes Yes Maximum width 63 3 4 3 4 4 4 4 4 4 4 4
anid eth accesstype atm xpon chassis rack frame slot subslot port port+1
Indicates the name of the access node. Indicates the ETH access mode. Indicates the access type of a user, used only on an xPON line. Indicates the ATM access mode. Indicates the xPON access mode. Indicates the chassis ID of the access node. Indicates the rack ID of the access node. Indicates the subrack ID. Indicates the slot ID. Indicates the sub slot ID. Indicates the port ID. Indicates port ID + 1. When the system constructs the CID/RID, Port ID = Actual port ID + 1. When the ANCP mode is the working object, the ancp port begin command and the port +1 keyword take effect at the same time. For example, if you use the port+1 keyword and also run the ancp port begin command to set the start port ID to 1, when the system constructs the CID/RID, Port ID = Actual port ID + 2.
ontportid cvlanid vlanid
Indicates the port ID of the ONT. Indicates the user VLAN. Indicates the user-side VLAN ID if the services carried on the user service port are differentiated by user-side VLAN ID. Otherwise, this VLAN ID is the networkside VLAN ID. In the case of the Layer 2 PPPoE and DHCP option 82 users, it is the priority of the traffic profile of the service port. Indicates the label of the user port. Indicates the label of the user service port.
Yes Yes Yes
4 4 4
priority
Yes
plabel splabel
No No
32 63
Issue 01 (2011-10-30)
672
Keyword
Description
Whether configura ble width Yes Yes Yes Yes Yes Yes
Maximum width 4 4 4 4 4 4
bslot bsubslot bport bporttype 8021p xpi
Indicates the rack ID of the access node. Indicates the sub slot ID of the BRAS. Indicates the port ID of the BRAS. Indicates the access mode of the BRAS. Indicates the VLAN priority. l When the network-side VLAN is a stacking VLAN, XPI is the network-side VLAN ID. l When the network-side VLAN is not a stacking VLAN, XPI is always 4096.
xci
l When the network-side VLAN is a stacking VLAN, XCI is the label of the user service port. l When the network-side VLAN is not a stacking VLAN, XCI is the network-side VLAN ID.
Yes
axpi (for the ATM access mode) axpi (for the ETH, xPON access mode) axci (for the ATM access mode)
Corresponds to VPI.
Yes
Corresponds to the network-side VLAN ID.
Yes
Corresponds to VCI.
Yes
Issue 01 (2011-10-30)
673
Keyword
Description
Whether configura ble width Yes
Maximum width 5
axci (for the ETH, xPON access mode)
l When the network-side VLAN is a stacking VLAN, If the services carried on the user service port are differentiated by user-side VLAN ID, AXCI is the user-side VLAN ID. If the services carried on the user service port are not differentiated by user-side VLAN ID, AXCI is the label of the user service port. l When the network-side VLAN is not a stacking VLAN, If the services carried on the user service port are differentiated by user-side VLAN ID, AXCI is the user-side VLAN ID. If the services carried on the user service port are not differentiated by user-side VLAN ID, AXCI is always 4096.
gem-index gemport uprate dnrate ontid ontlabel onuid onutag
Indicates the GEM index of the xPON line. Indicates the GEM port ID of the xPON line. Indicates the upstream rate of the ATM line port. Indicates the downstream rate of the ATM line port. Indicates the ONT ID of the xPON line. Indicates the ONT label. It is used only on an xPON line. Indicates the ONU ID of the xPON line. Indicates the string behind "ANID accesstype" in the tag carried by the ONU, used only on an xPON line. For example, in "ANID accesstype slot/ port:vlanid", onutag is "slot/port:vlanid".
Yes Yes Yes Yes Yes No Yes No
4 4 10 10 4 63 4 255
0002 up down
Always 0002 Always up Always down
Yes Yes Yes
4 2 4
Issue 01 (2011-10-30)
674
Keyword
Description
Whether configura ble width Yes Yes Yes Yes
Maximum width 4 4 2 -
vpi vci ge Plain text
Indicates the VPI of the ATM line. Indicates the VCI of the ATM line. Always GE In the case of flexible configuration, the RAIO format character string supports the plain text character string identified by " ". The plain text character string consists of characters, numbers, space, and the characters +*-/|.:<>[],#@$%!.
optional keyword
Enclosed in "[ ]". During the configuration of a RAIO format character string, it provides the ID for optional keywords. Keywords enclosed indicate the options. Currently, only cvlanid can be selected.
l l l
If the user defines the RAIO format according to the CID, the format character string must contain the keyword ANID. The keywords of interface types identify the formats of different interface types. The keywords mapping to different interface types cannot exist in the same format character string. For example, VPI and Gemport, or ETH and VCI cannot exist in the same format character string. If no interface type is specified, the CID/RID field mapping to the interface type is null. A separator represents the corresponding symbol that the user inputs in the RAIO format character string. The symbol that the separator represents is ultimately added to the CID/ RID. Table 18-10 lists the RAIO separators defined in the system.
l l
Table 18-10 User-defined separators Separator Space . : / % , Mark Space " " Period "." Colon ":" Slash "/" Hyphen "-" Percent "%" Comma ","
Issue 01 (2011-10-30)
675
Separator ; # !
Mark Semicolon ";" Number sign "#" Exclamation mark "!"
Other rules The length ranges from 1 to 127 characters, all of which are lowercase letters. The CID character string must contain the keyword ANID. The keyword ANID must exist before the keyword of the dependent interface type. All the separators before the keyword ANID in the CID character string, the RAIO separators (if any) in the system name that corresponds to ANID, and the separator behind ANID are the basis for the downstream packet to identify and parse the keyword ANID.
An example of an RAIO filed in the user-defined mode is as follows: Assume that: l l l l l l System name: DSLAM01 Slot ID: 3 Port ID: 15 VPI: 0 VCI: 35 Priority: 6
The user-defined CID character string is: anid atm slot/port:vpi.vci%priority The ultimate character string is: dslam01 atm 3/15:0.35%6
18.6 PITP
This topic provides an introduction to PITP, including the PITP P mode and PITP V mode, and describes the working principle of PITP.
18.6.1 Introduction
Definition
Policy information transfer protocol (PITP) is a protocol for implementing policy information transfer between the access device and the BRAS through Layer 2 P2P communication. PITP, including the PITP P mode and PITP V mode, is used to transfer the user physical port information, namely, relay agent information option (RAIO). l In the PITP V mode, the BRAS actively queries the user physical location information from the access device.
Issue 01 (2011-10-30)
In the PITP P mode, the access device adds the user physical location information in the PPPoE packets in the PPPoE discovery phase. This facilitates the user authentication by the BRAS.
Purpose
The purpose of the PITP feature is to provide the user physical location information for the upper-layer authentication server. After the BRAS obtains the user physical location information, the BRAS binds the information to the user account for authentication to prevent the user account from roaming or being forged.
Benefits
Benefits to carriers: With the PITP feature, carriers can provide high reliable services to build the brand and increase profit. Benefits to users: With the PITP feature, the user physical location information is bound to the user account to prevent the user account from theft.
The MA5600T/MA5603T supports the following specifications for the PITP feature: l l Two PITP modes, namely, PITP P mode and PITP V mode, are supported. PITP is supported at three levels, namely, system level, port level, and service port level. The access device provides the user physical location information to the BRAS only when PITP is enabled at all three levels. By default, PITP is disabled at the system level, but is enabled at the port level and the service port level.
18.6.3 Principle
Working Principle of the PITP P Mode
The PPPoE dialup process with the PITP P mode enabled is shown as Figure 18-2.
Issue 01 (2011-10-30)
677
Figure 18-2 PPPoE dialup process with the PITP P mode enabled
User MA5600T/MA5603T BRAS RADIUS Server
1 PADI
PADI+Tag PADO+Tag PADR+Tag PADS+Tag
With the PITP P mode enabled, in the PPPoE discovery phase, the device adds the user physical location information to the PPPoE packet sent from the user to cooperate with the upper-layer server to complete user authentication. The other phases are the same as those of the common PPPoE process. Thus, major differences between the PPPoE dialup process with the PITP P mode enabled and that without the PITP P mode enabled are as follows: l In the PPPoE discovery phase, all the PPPoE packets exchanged between the MA5600T/ MA5603T and the BRAS contain the user physical location information. The MA5600T/ MA5603T adds the user physical location information to the PPPoE packet after receiving the packet from the user, and forwards the packet to the BRAS. The MA5600T/ MA5603T removes the information from the PPPoE packet after receiving the packet from the BRAS, and forwards the packet to the user. If the PPPoE user needs to be authenticated on the RADIUS server, the BRAS extracts the user physical location information from the PPPoE packet that is sent from the MA5600T/ MA5603T and then adds the information to the authentication request packet for authentication.
Working Principle of the PITP V Mode

The PPPoE dialup process with the PITP V mode enabled is shown as Figure 18-3.
Discovery Session
2 PADO 3 PADR 4 PADS 5 LCP negotiation 6 Authentication packet
7 Request packet with user port information 10 Access accepted packet
9 Authentication pass packet
10 Data transmission
Issue 01 (2011-10-30)
678
Figure 18-3 PPPoE dialup process with the PITP V mode enabled
User MA5600T/MA5603T 1 PADI 2 PADO 3 PADR 4 PADS BRAS RADIUS Server
The three phases in the PPPoE dialup process are as follows: 1. 2. When the PPPoE discovery phase ends, the BRAS sends the PITP request packet to the BRAS, requesting for the user physical location information. After the device receives the PITP request packet, it queries the user physical location information such as the subrack ID, slot ID, and port ID according to the user MAC address and the VLAN information contained in the request packet. If querying the information is successful, the device adds the information to the response packet and then sends the packet to the BRAS. If querying the information fails, the device does not send the response packet to the BRAS.
3.
18.7 DHCP option82

DHCP option82 is similar to PPPoE+ as a user security mechanism. The information on a user's access location is added into the DHCP request packets initiated by a user for user authentication. This topic provides introduction to this feature and describes the principle and reference documents of this feature.
18.7.1 Introduction
Definition
Discovery Session
5 VBAS request packet 6 VBAS response packet 7 LCP negotiation 8 Authentication packet 9 Request packet with user port information 10 Access accepted packet
11 Authentication pass packet
12 Data transmission
DHCP option82 is similar to PPPoE+ as a user security mechanism. The information on a user's access location is added into the DHCP request packets initiated by a user for user authentication.
Purpose
DHCP option82 enables the DHCP request packets to carry the information on a user's access location for user authentication.
DHCP option82 takes effect only when it is enabled at all the following levels: l l l Global level Port level Service port level
18.7.3 Principle
Principle
Figure 18-4 shows the DHCP process when DHCP option82 is enabled. Figure 18-4 DHCP process with DHCP option82 enabled
User Discovery
MA5600T/ MA5603T
DHCP Relay Agent/ DHCP Server Discovery+Option82 Offer(+Option82)
Offer Request Request+Option82 ACK(+Option82) ACK Data transmission Release
The principle of DHCP option82 is similar to that of PPPoE+. The difference lies in that when a user requests for configuration, the MA5600T/MA5603T adds the information on the user's access location into the DHCP request packets from the user for authentication at the upper layer.
DHCP option82 Packet Format

For DHCP option82, you need to concern only about the option field in a DHCP packet, which is detailed in this topic. This field length is changeable. This field contains the following initial configurations for terminals and network configurations: l l l l l l l IP features Domain name Specific information for identifying a terminal IP address of the default gateway IP address of the default gateway IP address of the WINS server A user's valid lease term for an IP address
Figure 18-5 shows the format of a DHCP option82 field. Figure 18-5 Format of a DHCP option82 field
Code + | -----82 | Len + -----N + -----Agent Information Field + -----+ -----+ -----| iN | + -----+ + | i1 | i2 | i3 | i4 | + --- --- + ------
+ ------
Table 18-11 lists the meanings of each field in a DHCP option82 packet. Table 18-11 Fields of a DHCP option82 packet Field Code Len Agent Information Field Meaning One byte. This field is in the CLV format, used to uniquely identify the following information. 1 byte. This field indicates the length of the following information. This field indicates the information in bytes. The length is specified by the length field.
Option82 contains multiple sub options, which are contained in the value field of option82. Figure 18-6 shows the format of each sub option. Figure 18-6 Sub options of DHCP option82
SubOpt + + -----1 -----+ + Len -----N -----Sub- option Value + + ----------+ + ----------+ + -----| -----+ sN | + ----------| s1 | s2 | s3 | s4 |
Issue 01 (2011-10-30)
681
The two major sub options of option82 are: l Circuit ID (CID) This sub option is used to identify the local circuit identifier of DHCP proxy for receiving DHCP packets from a user. This field might contain router interface No. and ATM PVC No. The identifier is 1. l Remote ID (RID) This sub option is used to identify the remote host of a circuit. This field might contain the ATM address of a remote incoming and the modem ID. The identifier is 2. The MA5600T/MA5603T supports option82 in different formats. For details, see the section "18.5 RAIO."
18.8 802.1X
IEEE 802.1X (hereinafter referred to as 802.1X) is a port-based network access control protocol.
18.8.1 Introduction
Definition
IEEE 802.1X (hereinafter referred to as 802.1X) is a port-based network access control protocol. If a user connected to a port can pass the authentication, the user can access the resources in the network. In case of a failure to pass the authentication, the user cannot access the resources in the network. That is, the physical connection is cut off. The 802.1X port can be a physical port or a logical port.
Purpose
The MA5600T/MA5603T supports the port-based access authentication mode as specified in the standard. In addition, it extends and optimizes this authentication mode. As a result, the system security is improved and the system management function is enhanced.
The MA5600T/MA5603T supports the following specifications for the 802.1X feature: l l l l l l
Issue 01 (2011-10-30)
Access control mode based on the service virtual port In this mode, each service virtual port supports one user. Access control mode based on the port or "port+MAC address" In this mode, each port supports one user. 802.1X authentication triggered by EAPoL or DHCP Active detection function to actively trigger the 802.1X authentication Extended Keep Alive mechanism of 802.1X to detect the online status of users in real time EAP termination and EAP relay
18.8.3 Principle
Protocol System
802.1X defines the port-based network access control from the following aspects: l l l The access device provides the authentication control function of the access port (physical port or logical port). Before a port passes the authentication, the port is disabled and the users connected to the port cannot access the network resources. If the port passes the authentication, the port is enabled and the users can access the network. If the port does not pass the authentication, the port is disabled and the users cannot access the network.
The 802.1X system defines three functional entities: supplicant system, authenticator system, and authentication server system. Figure 18-7 shows the 802.1X system architecture. Figure 18-7 802.1X system architecture
Supplicant System Supplicant PAE Authenticator System Services offered by Authenticator' s System Authenticator PAE Uncontrolled port EAP protocol exchanges carried in higher layer protocol Authentication server system Authentication Server
Controlled port
Port unauthorized
LAN
In general, the digital user terminal provides the functions of the supplicant system entity and needs to be installed with the 802.1X client software, through which the supplicant system initiates authentication and quits authentication. The authenticator system authenticates the request from the supplicant. An authenticator system is usually an 802.1X-enabled network device, providing a service port for the supplicant. The service port can be a physical port or a logical port, and implements the 802.1X authentication of access users. The authentication server is an entity that provides the authentication service for the authenticator system. The 802.1X authentication server is usually located in the operator's AAA center. The ports of the authenticator system can be controlled ports or uncontrolled ports. l A controlled port is used to transmit the authenticated service packets. If a user passes the authentication, the controlled port changes to the authenticated state, and then the port can transmit the service packets. If the user fails to pass the authentication, the controlled port changes to the unauthenticated state, and the port cannot transmit the service packets.
Issue 01 (2011-10-30)
683
An uncontrolled port is always in the bi-directional connection state and can transmit authentication protocol packets, regardless of the authentication state (authenticated state or unauthenticated state) of the controlled port.
Feature Implementation
The MA5600T/MA5603T supports control over access users based on the physical port, service virtual port, or "physical port + MAC address". In the case of the authentication based on the physical port, 802.1X runs on one service virtual port of the port. If the port passes authentication, all other service virtual ports of the port are enabled. In the case of the authentication based on the "port + MAC address", only the packets with the MAC address that passes authentication are allowed to pass through the port. In the case of the authentication based on the service virtual port, a service virtual port is disabled before authentication. Once the authentication is passed, the service virtual port is enabled and in such a case, all user terminals of the service virtual port can access the network. In the case of the authentication by service virtual port, a service virtual port can be any of the following: l l An xDSL ATM service virtual port which is identified by the PVC or the PVC plus the user VLAN An xDSL PTM service virtual port which is identified by the user VLAN
The MA5600T/MA5603T supports the 802.lX authentication triggered by EAPoL or DHCP packets. You can set the method for EAPoL or DHCP packets to trigger the 802.1X authentication according to the terminal capability. With the 802.1X protocol running, the MA5600T/MA5603T works as an authenticator and receives the authentication requests from the users. In the case of a remote authentication, the MA5600T/MA5603T sends the authentication information to the RADIUS server for authentication. If an access port passes the authentication of the RADIUS server, it is enabled. The MA5600T/MA5603T supports the EAP termination and EAP relay modes. l In the EAP termination mode, the MA5600T/MA5603T abstracts the user authentication information from the EAP packets, encapsulates the information into the corresponding attribute of the RADIUS protocol, and then sends the information to the RADIUS server for authentication. In the EAP relay mode, the MA5600T/MA5603T encapsulates the EAP packets into the corresponding attribute of the RADIUS protocol, and sends the packets to the RADIUS server for authentication. In this mode, the RADIUS server needs to process the EAP packets.
18.9 Anti MAC Spoofing

This topic provides an introduction to the anti MAC spoofing feature and describes the working principle of this feature.
Issue 01 (2011-10-30)
684
18.9.1 Introduction
Definition
MAC spoofing is an attack in which malicious users send packets with forged MAC addresses to attack the system. Malicious users can forge the MAC addresses of authorized users to damage the services of these users. Malicious users can also transmit a large number of forged packets that contain different MAC addresses to the system, which affects the normal operation of the system or even causes the system to crash. Anti-MAC spoofing is a countermeasure that is taken by the system to prevent a user from attacking the system with a forged MAC address.
Purpose
To protect the system and the network of a carrier, the following measures are taken to prevent malicious users from forging the MAC address of the authorized users to attack the system or network. 1. MAC address binding l For authorized users that access a carrier's network following the PPPoE or DHCP online process, the system dynamically binds the MAC addresses and allows users with the limited and trustful MAC addresses to access the network. Users with untrusted MAC addresses are prohibited from entering the network. l For authorized users that do not access a carrier's network following the PPPoE or DHCP online process, the system binds the static MAC addresses of the users and allows users with the limited and trustful MAC addresses to enter the network. 2. Anti-MAC duplicate After anti-MAC duplicate is enabled, the system regards the first MAC address learned by the port as a valid MAC address. Before the MAC address is aged, the system does not allow duplication of the MAC address. 3. VMAC can also prevent MAC address conflicts and protects users from MAC address spoofing. VMAC includes 1:1 VMAC and N:1 VMAC.
MAC Address Binding
The specifications are as follows: l l Static binding: The system supports up to 1K static MAC addresses. The number of the static MAC addresses that can be bound to a traffic stream is not limited. Dynamic binding The system can be bound with up to 8K traffic streams. Each traffic stream can be bound with up to 8 MAC addresses. If each traffic stream is bound with 8 MAC addresses, then the system can be bound with up to 1024 traffic streams.
Anti MAC Duplicate

The specifications are as follows:
l l l
Supports PPPoE and IPoE users. The IPoE users include those with static IP addresses and those with dynamic addresses allocated by DHCP. Supports user-side anti MAC duplicate (supported by SCUN, xDSL, and GPBD). Supports network-side anti MAC duplicate (supported by SCUB, SCUN, ETHA, ETHB, SPUA, and GIU).
NOTE
According to the default setting, MAC addresses learned from the network side are preferentially ensured during the initialization of the SCUN control board to avoid being overwritten by those learned from the user side. Such a default setting is not affected by anti MAC duplicate.
Supports the global setting of anti MAC duplicate.
18.9.3 Impact of MAC Spoofing

As shown in Figure 18-8, the impact of MAC spoofing is as follows: l l l l PC1 and PC2 use the PPPoE service. PC1 uses the MAC address of the BRAS server as its source MAC address to send packets. The forwarding entries on the access device are changed. As a result, the PPPoE service packets of PC2 are sent to PC1 instead of to the BRAS server. Normal services of PC2 fail.
Figure 18-8 Impact of MAC spoofing

BRAS Original services fail Direction of the packets is changed Access service
Modem PC1 Sends packets with the MAC address of the BRAS server as its source MAC address
Modem PC2
18.9.4 MAC Address Binding

Binding Dynamic MAC Addresses
1. The system disables users' dynamic MAC address learning and monitors their online and offline processes. When a user goes online, the system dynamically obtains the user' source
Issue 01 (2011-10-30)
MAC address and sets up the binding relationship between the user's source MAC address and the user port or between the user's source MAC address and the traffic stream. 2. 3. Only the service packets whose source MAC addresses are bound to the user port or traffic stream are allowed to pass through the device. When the user goes offline, the system unbinds the source MAC address of the user from the user port or traffic stream.
In an IPv4 network, the first valid packet sent by a CPE is a DHCP Discover or PPPoE Discover packet, which triggers anti-MAC spoofing. After obtaining the DHCP Discover or PPPoE Discover packet, the MA5600T/MA5603T verifies that no MAC address conflict occurs and binds the MAC address of the CPE to the user port or traffic stream. Anti-MAC spoofing can be enabled or disabled globally or based on VLAN. l After anti-MAC spoofing is enabled, the MA5600T/MA5603T stops dynamic MAC address learning of the service boards and captures DHCPv4 and PPPoE packets from the user side and network side. After anti-MAC spoofing is disabled, the MA5600T/MA5603T resumes dynamic MAC address learning on the service boards and no longer captures PPPoE or DHCPv4 packets from the user or network side. The MA5600T/MA5603T also deletes its MAC address binding entries.
Binding Static MAC Addresses

The system disables users' dynamic MAC address learning and sets up the binding relationship between users' source MAC addresses and user ports or between users' source MAC address and traffic streams by using the NMS or the CLI.
18.9.5 Anti MAC Duplicate

When the anti MAC duplicate function is enabled on the user side, the system regards the first MAC address learned by a user-side port as a valid address. Before the MAC address is aged, the system does not allow duplication of the MAC address to any other user-side port. When the anti MAC duplicate function is enabled on the network side, the MAC address learned by a network-side port is not duplicated to any other network-side port or any user-side port.
NOTE
According to the default setting, MAC addresses learnt from the network side are preferentially ensured during the initialization of the SCUN control board to avoid being overwritten by those learnt from the user side. Such a default setting is not affected by anti MAC duplicate. Therefore, the SCUN control board supports MAC address duplication between network-side ports.
18.10 Anti-IP Spoofing

This topic covers the definition and principle of the anti-IP spoofing feature.
Definition
IP spoofing is an attack in which malicious users send packets with forged IP addresses to attack the system. Malicious users can forge the IP addresses of authorized users to damage the services of these users.
Anti-IP spoofing is a countermeasure that is taken by the system to prevent a user from attacking the system with a forged IP address.
Purpose
To protect the system and the network of a carrier, for authorized users that access the network following the DHCP online process, the system dynamically binds MAC addresses and allows the users with trustful IP addresses to enter the network. Users with untrusted IP addresses are prohibited from entering the network. For authorized users that do not access a carrier's network following the DHCP online process, the system binds the static IP addresses of users and allows the users with trustful IP addresses to enter the network.
Benefits
Benefits to carriers: Anti-IP spoofing, using dynamic or static IP address binding, protects the carrier's network from being attacked. Benefits to users: Anti-IP spoofing, using dynamic or static IP address binding, enhances the security of user services.
The specifications of the anti-IP spoofing feature are as follows: l l Static binding: The MA5600T/MA5603T supports a maximum of 8K traffic streams. Each traffic stream can be bound to eight IPv4 prefixes. Dynamic binding: Dynamic binding can be enabled or disabled globally or for a service port. By default, dynamic binding is disabled globally and is enabled for a service port. The anti-IP spoofing function for a service port takes effect only when dynamic binding is enabled at both two levels. The system supports a maximum of 8K dynamic IP addresses. The system supports dynamic binding of a maximum of 8K traffic streams. Each traffic stream can be bound to a maximum of eight IPv4. l The system supports to disable anti-IP spoofing from taking effect on IGMP packets .
18.10.3 Principle
Dynamic IP Address Binding for Anti-IP Spoofing
l After the dynamic IPv4 address learning function is disabled, the system monitors users' DHCP online and offline processes. When a user goes online, the system dynamically obtains the user's source IPv4 address and binds the user's source IPv4 address to a traffic stream. The system only allows the packets with source IPv4 addresses bound to the user port or traffic stream to pass through. When a user goes offline, the system unbinds the user's source IPv4 address from the traffic stream.
l l
Issue 01 (2011-10-30)
Static IP Address Binding for Anti-IP Spoofing

The MA5600T/MA5603T allows you to bind IPv4 addresses to user ports. After IP addresses are bound to a user port, the user port only allows packets with IP addresses bound to the port to pass through. This improves system security.
18.11 User Isolation

This topic provides an introduction to the user isolation feature and describes the working principle of this feature.
Definition
The MA5600T/MA5603T supports the MUX VLAN and the Smart VLAN. The MUX VLAN divides user services into different virtual local area networks (VLANs). The services of each VLAN are isolated, thus restricting visits between users in different VLANs. Different service ports in the same Smart VLAN are also isolated, thus restricting visits between users in the same VLAN.
Purpose
Users are restricted to visit each other when the user service flows or service ports are divided into different VLANs or the user service flows or service ports in the same VLAN are isolated by the Smart VLAN. Hence, the security of user services is ensured.
Benefits
For the carrier: The carrier can improve its brand value by providing high-security services. For users: Users can enjoy high-security networks.
The specifications of the user isolation feature are as follows: l l MUX VLAN Smart VLAN
18.11.3 Principle
Working Principle
The MUX VLAN realizes user isolation by dividing the user service flows or service ports into different VLANs. The Smart VLAN restricts visits between users by isolating the service flows or service ports in the same VLAN.
18.12 Line Security of the GPON System

Definition
The downstream data of the GPON is transmitted in the broadcast mode, and thus information may be intercepted. Therefore, the encryption technology needs to be used on the line between an OLT and an ONU to enhance the data security and ensure the secure transmission of information over the line. The advanced encryption system-Federal Information Processing Standard 197 (AES-FIPS 197) is the latest encryption standard issued by the National Institute of Standards and Technology (NIST) of the USA. The AES algorithm can use 128-bit, 192-bit, and 256-bit encryption keys to encrypt or decrypt 128-bit data blocks to protect electronic data.
Purpose
The GPON system uses the AES128 encryption mechanism for line security control, and thus effectively prevents security problems such as data embezzlement.
The system enables or disables the encryption function based on GEM ports. The encryption function is disabled by default.
18.12.3 Principle
Working Principle
The AES algorithm can use 128-bit, 192-bit, and 256-bit encryption keys to encrypt or decrypt 128-bit data blocks to protect electronic data. The AES algorithm replaces the DES and 3DES algorithms with low security. The AES128 encryption feature can be used to randomly select a key from as many as 3.4 x 1038 unique password keys to encrypt bit streams. Therefore, accurate hacker programs that can decrypt one million encryption keys in a second (very advanced concurrent algorithm capability) need thousands of 100 billion years to find the encryption key generated through the AES-128 encryption feature. In the AES128 encryption system, the MA5600T/MA5603T support key change and switchover. 1. 2. 3. When key change is required, an OLT sends a key change request. After receiving the key change request, an ONU (ONT or MDU) gives a response and generates a key. The length of a PLAOM message is limited. Therefore, the generated key is sent to the OLT in two parts and for three times repeatedly. If the OLT does not receive the key in any of the three times, the OLT resends the key change request. The OLT stops sending the key change request until it receives the same key for three times. After receiving the new key, the OLT starts the key change.
4.
Issue 01 (2011-10-30)
5.
The OLT notifies the ONU (ONT or MDU) of the new key by sending a command containing the frame number and new key. Generally, this command is sent for three times. As long as the ONU receives the command once, it switches the check key on the corresponding data frame.

Glossary Smart VLAN Description A smart VLAN is a VLAN that can contain multiple upstream ports and multiple service ports. The service ports in one smart VLAN are isolated from each other. A MUX VLAN is a VLAN that can contain multiple upstream ports but only one service port. The traffic streams of different MUX VLANs are isolated.
MUX VLAN
Acronym/ Abbreviation AES BRAS DHCP DoS GPON ICMP LLID MAC MIB PITP RAIO SNMP SSH
Full Spelling Advanced Encryption Standard Broadband Remote Access Server Dynamic Host Configuration Protocol Denial of Service Gigabit-capable Passive Optical Network Internet Control Message Protocol LLID Logical Link Identifier Media Access Control Management Information Base Policy Information Transfer Protocol Relay Agent Info Option Simple Network Management Protocol The Secure Shell
Issue 01 (2011-10-30)
691
19 Line Optimization and Line Test
19
Line Optimization and Line Test
About This Chapter

This topic describes the basic features and principles of the line optimization and line test. 19.1 Line Optimization This topic describes the line optimization feature in its introduction, principle, and reference. 19.2 SELT Test This topic describes the basic feature and principle of the SELT test. 19.3 MELT This topic describes the basic feature and principle of the metallic line testing (MELT).
Issue 01 (2011-10-30)
692
19.1 Line Optimization

This topic describes the line optimization feature in its introduction, principle, and reference.
19.1.1 Introduction
Definition
Line optimization is a function where in the N2510 collects and analyzes the running parameters of the xDSL line, calculates the parameters by using the optimization algorithm, and then outputs the best parameters of the optimized profile for each line. After the user issues the parameters of the optimized profile manually, the line rate and stability can improve to the best state.
Purpose
The current situation of the xDSL lines is that the crosstalk of a bundle of lines is large, and the line conditions are not as expected because of the distance or other radio interference. The crosstalk and interference lower the performance of the xDSL lines. N2510 can automatically collect the running parameters of the lines in the entire network through its line optimization feature. When the user needs to optimize a line, the user can specify the optimization target by binding a service profile to the line that is to be optimized. When the optimization task is started, the N2510 analyzes the to-be-optimized line according to the optimization target specified by the user in the service profile and according to the collected running parameters of the line. By using the optimization algorithm, the N2510 calculates the best line profile parameters that are suitable for each line. The recommended parameters can effectively increase the line rate and improve the line stability after being used in the line. In this manner, the line optimization feature helps the user develop the potential of the existing network and improve the operation quality without requiring additional investment and workload of the user.
The MA5600T/MA5603T supports the following specifications of the Line optimization feature: l Collecting of the DLM/DSM optimization information of a specified board and query of the collecting status of the DLM/DSM optimization information of a specified board or all boards Displaying the parameters of the xDSL port, including the Hlog(i) of each sub-carrier, Qln (i) of each sub-carrier, TxPSD(i) of each sub-carrier, SNR(i) of each sub-carrier, SNRM(i) of each sub-carrier, gi of each sub-carrier, bi of each sub-carrier, coding gain, and actual size of Reed-Solomon codeword (NFEC) 1000 optimization profiles you can add, modify, delete, and query an optimization profile. The parameters in the optimization profile are classified for configuration. The parameters configured in an optimization profile are as follows: Line transmission mode Upstream/downstream bit swap parameters
SNR (Signal Noise Ratio) margin, including upstream/downstream target SNR margin, upstream/downstream minimum SNR margin, and upstream/downstream maximum SNR margin Upstream/downstream interleave delay Upstream/downstream INP Power management parameters, including whether the transition to the idle state is allowed, whether the transition to the low power state is allowed, the shortest time for a line to be in the full-power state, the minimum time between entry into the L2 low power state and the first L2 low power trim request and between two consecutive L2 power trim requests, each transmit power reduction in the L2 power state, and the maximum aggregate transmit power reduction that is allowed in the L2 power state Upstream/downstream sub-carrier blackout parameters Mode-related parameters, including transmission mode, maximum upstream/ downstream aggregate nominal transmit power, upstream/downstream PSD mask, and maximum upstream/downstream aggregate nominal transmit power l Bind of an optimization profile to a port and unbinding of an optimization profile from a port
19.1.3 Reference
The following lists the reference documents of this feature: l l Description of MA5600 xDSL Feature Software Requirements and Specifications Details About VDSL2 Parameters
19.1.4 Availability
License Support
The DLM/DSM feature is an optional feature of the MA5600T/MA5603T, and the corresponding service is under license. The following resources are under license: l l l l VDSL port AnnexM resources INP+ resources Resources bound to the optimization profile
Version Support
Table 19-1 Version Support Product MA5600T/MA5603T Support V800R006C02 and later
Hardware Support
The VDSA, VDTF, VDJM, VDNF, VDMF, VDPE, and VDPM boards support the DLM/DSM feature.
Limitation
When configuring an optimization profile, make sure that the parameters meet the following conditions: l l For the upstream SNR: maximum SNR margin target SNR margin minimum SNR margin For the power status parameter: each transmit power reduction in the L2 power state maximum aggregate transmit power reduction that is allowed in the L2 power state
19.1.5 Principle
Compatibility of the Line Optimization Feature
The DLM/DSM feature supports the optimization of the line in the xDSL access mode.
System Architecture of the Line Optimization Feature

The system architecture of the line optimization feature is an independent application model based on xDSL and the MIB browser. l l l l The line optimization profile is a concept similar to the xDSL profile. The N2510 is a platform similar to the NMS platform. Line optimization is mainly performed by the N2510. The MA5600T/MA5603T mainly collects the line optimization information and, according to the optimized line, configures the parameters.
The overall process of the line optimization is as follows: The system analyzes the history running parameters of the subscriber line to determine the proper line encoding parameters, and determines a proper line rate according to the optimization target specified by the user. Based on the line rate and line encoding parameters, the system analyzes the crosstalk between subscriber lines to determine the optimal modulation parameters. The specific process of the line optimization is as follows: 1. 2. Before the optimization process is started, the user determines the target rate of the line through the service profile. After the optimization process is started, the system analyzes the running parameter of the recent period. Generally, the period is one week in which the running status of the line in various conditions can be covered. Then, the system determines the optimal modulation parameters of the line. Based on the known modulation parameters and the target rate specified by the user through the service profile, the system calculates the optimal line rate. The system adjusts the line modulation parameters to achieve the optimal transmit power and reduce crosstalk between subscriber lines. The transmit power can be adjusted at two levels. By adjusting the maximum transmit power of the entire line, which is called the single-pair power adjustment, dynamic line management (DLM) for short. DLM is to adjust (reduce) the power of a single line regardless of the interference with adjacent lines. By adjusting the transmit power spectrum of lines, which is called the multi-pair power adjustment, dynamic spectrum management (DSM) for short. The power adjustment by
3. 4.
In step 4 of the line optimization, the transmit power can be adjusted at the following two levels: l
Issue 01 (2011-10-30)
the DSM must be performed on multiple lines in a cable. It focuses on calculating the optimal power spectral density (PSD) of each line according to the crosstalk between lines. This can minimize the crosstalk between lines. Both DLM and DSM can effectively reduce the line power and improve the line stability. Compared with DLM, DSM can optimize multiple related lines in the entire network, and can balance the performance and crosstalk of multiple lines. When the topology structure of lines is clear, DSM is a better power adjustment mode. Figure 19-1 Topology of the line optimization feature
OSS
xml N2000BMS xml
xml
N2510
OLT
DSLAM
VDSL2
DSLAM
USER
USER

Glossary
Table 19-2 Glossary of the terms related to the DLM/DSM feature Term Noise margin Description The SNR margin refers to the space that is reserved when the system allocates bits. When decrease of the SNR caused by the environment change does not exceed the SNR margin, the BER can be guaranteed to be less than 10-7.
Issue 01 (2011-10-30)
Term Interleaved delay
Description Interleave causes delay. Interleave delay is composed of two parts: FEC coding time and interleave time.

Table 19-3 Acronyms and abbreviations of the DLM/DSM feature Acronym/Abbreviation DLM DSM SNR NFEC INP Full Spelling Dynamic line management Dynamic spectrum management Signal noise ratio Actual size of reed-solomon codeword Impulse noise protection
19.2 SELT Test

This topic describes the basic feature and principle of the SELT test.
19.2.1 Introduction
Definition
Single ended loop test (SELT) is an automatic test method for testing the DSL loop from one end of the line. SELT test provides operators with an effective method for evaluating the loop in daily operation.
Purpose
The SELT test obtains the line information before or after the line is used. The information includes line length, line reachable rate, and line noise. Through the information, you can know the future serviceability of the line.
The specifications of the SELT feature are as follows: l l l l
Issue 01 (2011-10-30)
Supported by the ADSL2+, ADSL2, ADSL, and VDSL2 ports. Valid ranging range: 300 m to 2.5 km. Precision of line length test: 15% (applicable to the 0.4 mm and 0.5 mm core diameters). Test duration: within three minutes.
l l l l l
SELT can be performed on only one port of an entire subrack at a time. The SELT test can be started on the VDSL2 port and the test result can be queried through the CLI. The SELT test can be started on the VDSL2 port through the NMS. The NE can report the SELT result to the NMS through traps. Currently, the following SELT parameters are supported: Subrack ID/slot ID/port ID Update time: year-month-date hh:mm:ss Line length Line terminal status Core diameter SNR margin (dB), upstream rate (kbit/s), and downstream rate (kbit/s).
l l
Supports the quiet line noise (QLN) test function. Supports the uncalibrated echo response (UER) test function.
NOTE
H805ADPD, H80BCAME, H80BADPE, H805VDMF, H805VDRD, H80BVDPE, H80BVDPM support UER.
19.2.3 Availability
Hardware Support
This feature is supported by all the ADSL and VDSL boards.
Impact
l l l l l l Before performing the SELT test, the port to be tested must be deactivated. During the SELT test, all the services carried on this port are interrupted. During the SELT test, the port status changes to Testing. After the test, the test result is displayed. During the SELT test, the board resets. When the board works in the normal state, it does not restart automatically. The SELT stops after an active/standby switchover. The SELT result can be cleared in the global config mode.
19.2.4 Principle
Figure 19-2 shows the SELT test principle.
Issue 01 (2011-10-30)
698
Figure 19-2 SELT test principle
TX
AFE
In the SELT test, the analog front end (AFE) transmits test signals. When the test signals pass through the place where the impedance is discontinuous, the test signals are reflected. The AFE receives and analyzes the reflected signals, and then obtains the line condition. SELT test does not need the cooperation of customer premises equipment (CPE). The test distance is affected by line signal attenuation because the SELT test signals pass through double line length. SELT test methods include: l l Time domain reflectometry (TDR), testing the time-voltage relationship between transmitted signals and reflected signals. Frequency domain reflectometry (FDR), testing the frequency-voltage relationship between transmitted signals and reflected signals.
DSP
RX
Test signal Twisted pair
19.3 MELT
This topic describes the basic feature and principle of the metallic line testing (MELT).
19.3.1 Introduction
Definition
MELT is a narrowband line test that is performed on the DSL line from one end of the line. The test items of MELT include the voltage, resistance, and capacitance of the line.
Purpose
According to the MELT test results, faults such as grounding, open circuit, and short circuit can be clearly diagnosed on the line. Generally, line expert systems similar to the N2510 can be used for analyzing the test results and locating the fault.
The specifications of the MELT feature are as follows: l l l Supported by the ADSL2+, VDSL2, and SHDSL ports Supports parallel port tests: Each board supports test on only one port, but the system supports test on multiple ports (up to 16). Supported test items: Extraneous AC voltage Extraneous DC voltage Insulation (A/E, B/E, A/B, B/A) Capacitance (A/E, B/E, A/B) Support search tone test
NOTE
l A and B refer to the two wires of a twisted pair. A refers to the tip, and B refers to the ring. l E refers to the ground cable.
The accuracy of MELT: Table 19-4 The accuracy of DC voltage DC voltage 0 V to 20 V 20 V to 250 V Resolution 100 mV 1V Accuracy 1V 5%
Table 19-5 The accuracy of AC voltage AC voltage 0 V to 20 V 20 V to 250 V Resolution 100 mV 1V Accuracy 1V 5%
Table 19-6 The accuracy of DC resistance Resistance 0 ohm to 250 ohm 250 ohm to 1 kilohm 1 kilohm to 100 kilohm 100 kilohm to 1 megohm 1 megohm to 5 megohm
Issue 01 (2011-10-30)
Resolution 1 ohm 1 ohm 10 ohm 100 ohm 10 kilohm
Accuracy 10 ohm 4% 4% 8% 15%

700
Resistance 5 megohm to 10 megohm
Resolution 10 kilohm
Accuracy 25%
Table 19-7 The accuracy of DC capacitance Capacitance 0 nF to 20 nF 20 nF to 1 F 1F to 5 F Resolution 1 nF 1 nF 0.1 F Accuracy 1 nF 5% 10%
19.3.3 Availability
Hardware Support
l This feature is supported by the ADKM, VDJM, VDPM, SHLM, and CAME boards.
Impact
l l MELT does not affect the broadband service of the local line or neighboring lines (MELT impact can be ignored). The MELT test results can be cleared by running a command in the global config mode.
19.3.4 Principle
Figure 19-3 shows the MELT test principle. Two applications are included: one is to test the electrical parameters of the line and the other is to test the voice signal receiving capability of the line. During the test, the two applications are mutually exclusive. Figure 19-3 MELT test principle
Issue 01 (2011-10-30)
701
Testing electrical parameters

In the MELT test, the MELT test chip sends test signals to the target port for testing related electrical parameters, and then the chip calculates the major physical parameters of the cable. (In certain application scenarios, the MELT test chip can be regarded as a multimeter that can test the voltage, resistance, and capacitance.)
NOTE
During the MELT test process, service running is not affected.
Table 19-8 lists the MELT test items. Table 19-8 Test items Test Item AC voltage DC voltage Full resistance Full capacitance Description A line to ground AC voltage, B line to ground AC voltage, and A line-B line AC voltage A line to ground DC voltage, B line to ground DC voltage, and A line-B line DC voltage A line to ground resistance, B line to ground resistance, A lineB line resistance, and A line-B line polarity reversal resistance A line to ground capacitance, B line to ground capacitance, and A line-B line capacitance
Search tone test

Figure 19-4 shows the principle of search tone test. When starting test, the search tone shall be applied symmetrically between a-wire and b-wire. The frequency of the search tone shall be 800 Hz. Search tone level at xDSL ports: between 120 mV and 330 mV (RMS) at 600 ohm. Figure 19-4 The principle of search tone test
Issue 01 (2011-10-30)
702
20 Operation and Maintenance
20
About This Chapter
20.1 Introduction
Operation and Maintenance
The operation & maintenance (O&M) feature is intended for the operation, administration and maintenance (OAM) of the device. It plays an important role in guaranteeing the normal running of the device on the daily basis, managing the device in the network topology, locating faults, and upgrading and maintaining the device. This topic describes the sub features of the O&M feature in details.
20.2 Reference Standards and Protocols 20.3 Remote Operation 20.4 Ring Check The ring check feature is mainly used to detect and eliminate the user-side ring network. 20.5 ANCP The Access Node Control Protocol (ANCP) is used by the broadband network gateway (BNG) to manage the line parameters (including QoS and user) of the access node (AN). 20.6 Environment Monitoring In general, environment monitoring involves environment parameters monitoring and power monitoring. Environment parameters monitoring refers to monitoring of the environment parameters that might cause failure or damage to the system. Power monitoring refers to monitoring of the power supply system. 20.7 Power Saving and Maintenance This topic describes the power saving feature of the system from two aspects: stepless speed adjustment of the fan and power cutoff of the board. It also describes the maintenance feature of the system from two aspects: power cutoff of the board and recording the model and running information for the fan and power module. 20.8 ONT DHCP Simulation In FTTH scenarios, when services (such as IPTV and VoIP) obtaining IP addresses by DHCP fail, users can perform DHCP simulation on the ONT to quickly locate the fault.
Issue 01 (2011-10-30)
703
20.1 Introduction
The operation & maintenance (O&M) feature is intended for the operation, administration and maintenance (OAM) of the device. It plays an important role in guaranteeing the normal running of the device on the daily basis, managing the device on the network topology, locating faults, and upgrading and maintaining the device. The following considers the MA5600T/MA5603T as an example to describe the O&M feature and its sub features from the aspects of definition, purpose, specifications, principle, and reference standards and protocols. This helps the intended audience to have a thorough understanding of the MA5600T/MA5603T O&M feature. The MA5600T/MA5603T O&M feature includes a number of sub features such as user management and remote operation, program and configuration data management, device anomaly management, access node control protocol (ANCP), and MA5600T/MA5603T registration and authentication.

The following lists the reference documents of operation and maintenance: l l l l l IETF RFC0854 Telnet Protocol Specification IETF RFC0793 Transmission Control Protocol ITU-T X.733 ITU-T G.984.3 IEEE 802.3ah
20.3 Remote Operation

20.3.1 Introduction
Definition
Remote operation refers to performing routine maintenance on the device remotely, without any on-site visit.
Purpose
This sub feature facilitates carriers in maintaining remote device.
Benefits
Benefits to carriers: The carriers' operating expenditure (OPEX) is saved considerably, and the customer satisfaction is increased. Benefits to users: Services provided for users, if abnormal, can return to the normal within the shortest period after the carriers locate and troubleshoot the abnormal services quickly.
20.3.2 Principle
The MA5600T/MA5603T supports Inband telnet and outband telnet. l Outband telnet The interface used by outband telnet is the only one Ethernet port (RJ-45) on the front panel of the control board. After the IP address and related route are configured on this port, the device can be logged in to through this port in the telnet mode for related operations and maintenance. l Inband telnet The interface used by inband telnet is the VLAN Layer 3 interface inside the device. The system supports up to 32 IP addresses for the VLAN Layer 3 interface and the subnets of these IP addresses must be different. In the case of remote telnet, it is recommended to configure the acceptable/refused IP address segments to prevent the login of a user who uses an illegal IP address.
20.4 Ring Check

The ring check feature is mainly used to detect and eliminate the user-side ring network.
20.4.1 Introduction
Definition
Ring check is a function of detecting the ring network formed on the user side. The ring check feature enables the device to transmit the ring check packets to the user port periodically, and to monitor the ring check packets received on the user side and the network side to check whether a loop occurs on the network of the carrier. If a loop occurs, the MA5600T/MA5603T deactivates the user ports on the loop and reports the corresponding alarm to the NMS. This ensures that the device runs in the normal state and that the services of other users are not affected.
Purpose
Ring check is used to quickly locate the user-side ring network, and eliminate the ring network according to requirements. l l l To prevent the self-loop on a single user port from occurring To prevent the loop between user ports from occurring To prevent the loop between a user port and a network port from occurring
Benefit
Benefits to carriers The Ring check feature enables the system to detect the carrier's network and report an alarm to the NMS when a loop occurs. The alarm enables the carrier to know the network fault in the shortest period of time so that the fault can be quickly rectified to resume the normal running of the network. Benefits to users
The Ring check feature enables the device to deactivate the user port on a loop to ensure that authorized users receive a good network service rather than be affected.
l l l Supports the ring check function on the user side. Supports the configuration of the protocol type of the ring check packet, ranging from 0x601 to 0xFFFF. By default, the protocol type value is 0x8300. Supports deactivation of user ports forming a ring network. Supports deactivation of the xDSL ports forming a ring network by subrack ID/slot ID/ port ID. Supports deactivation of the ETH ports forming a ring network by subrack ID/slot ID/ port ID. Supports deactivation of the ONTs forming a ring network by ONT ID.
20.4.3 Availability
License Support
The ring check feature is a basic feature of the MA5600T/MA5603T. Therefore, the corresponding service is provided without a license.
Version Support
Table 20-1 Version Support Product MA5600T/MA5603T Version V800R006C02 and later versions
20.4.4 Principle
Format of the Ring Check Packet
The ring check feature enables the device to transmit the ring check packets to the user port periodically, and to monitor the ring check packets received on the user side and the network side to check whether a loop occurs on the network of the carrier. Figure 20-1 shows the format of the ring check packet. Figure 20-1 Format of the ring check packet
DMAC 802.1Q Head Type Payload Payload

Issue 01 (2011-10-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
SMAC Payload
706
l l l l
DMAC indicates the broadcast MAC address with value 0xFF and SMAC indicates the bridge MAC address. 802.1Q Head is optional according to flow attributes on the user side. Type indicates the proprietary Ethernet type, which can be configured. Payload of the packet content is proprietary and it needs not be configured.
Principle
After the ring check function is enabled, the device periodically transmits private ring check packets to the user port and captures the user-side ring check packets on the network and user sides simultaneously. l As for the ring check packets captured on the network side, the system first checks whether they are transmitted from the local device. If yes, the system finds out the source port transiting the ring check packets and reports an alarm to the NMS, but does not deactivate this source port. This is because a user can forge the ring check packets and the system cannot determine whether the ring check packets are forged by a user or are transmitted from the device. The check performed by the system prevents misjudgment of the check point. If not, the system discards the packets. l As for the ring check packets captured on the user side, the system reports an alarm to the NMS and deactivates the port receiving the packets, thus eliminating the loop in the network. Assume that the system supports 8K traffic streams. The ring check function checks 300 traffic streams every second. If a ring network occurs, it can be checked after 8000/300 = 26.67s.
Figure 20-2 shows the use-side ring network scenarios in FTTH/DSLAM applications. l In the case of (1), (2), (3), and (4), as for the ring check packets captured on the user side, the system directly deactivates the port receiving the packets, thus eliminating the loop in the network. In the case of (4), this kind of network topology needs to be prevented. This is because the system cannot determine whether the ring check packets captured on the network side are forged by a user or are transmitted from the device. This kind of network topology prevents misjudgment of the check point.
Figure 20-2 Use-side ring network scenarios in FTTH/DSLAM applications
Issue 01 (2011-10-30)
707
Figure 20-3 shows the use-side ring network scenarios in FTTB/FTTC applications. l The Ethernet Types of ring check packets of the OLT and the MDU are recommended to be the same. If Ethernet Types of ring check packets of the OLT and the MDU are the same, the ring check packets are captured on the OLT and the MDU and are judged. In the case of (6), the ring check packets transmitted by the MDU are terminated by the OLT. Therefore, ring network cannot be detected in this kind of network topology. If Ethernet Types of ring check packets of the OLT and the MDU are different, the OLT and the MDU capture its own ring check packets. In the case of (4), the MDU and the ONT connected to the OLT are not interconnected. Therefore, ring network cannot be detected in this kind of network topology. l In the case of (1), (2), (3), and (4), as for the ring check packets captured on the user side, the system directly deactivates the port receiving the packets, thus eliminating the loop in the network. In the case of (5), the system can detect the ring network but not deactivate the port to eliminate the ring network, instead, the system reports an alarm. In the case of (5) and (6), these two kinds of network topology need to be prevented. This is because the system cannot determine whether the ring check packets captured on the network side are forged by a user or are transmitted from the device. This kind of network topology prevents misjudgment of the check point.
Figure 20-3 Use-side ring network scenarios in FTTB/FTTC applications
Issue 01 (2011-10-30)
708
20.5 ANCP
The Access Node Control Protocol (ANCP) is used by the broadband network gateway (BNG) to manage the line parameters (including QoS and user) of the access node (AN).
20.5.1 Introduction
Definition
The Access Node Control Protocol (ANCP) is used by the broadband network gateway (BNG) to manage the line parameters (including QoS and user) of the access node (AN).
NOTE
A BNG can be a BRAS or a router, such as the MA5200G.
Figure 20-4 displays the NEs relevant to ANCP. l l l The user powers on, disables, or connects the RG to change the line status. The BNG and the AN exchange ANCP messages. The network administrator manages the AN through the N2000 BMS by using SNMP.
Figure 20-4 ANCP network topology

N2000 BMS
BNG
eg. MA5200G
User
SN M P
RG RG
AN
P AN C
User
Purpose
When ANCP is not used, if the BNG needs to manage the line parameters of an AN, the NMS is required. When the AN and the BNG use different NMSs, the line parameters are hard to be managed. Through ANCP, however, the BNG can directly manage such parameters without the NMS.
ANCP supports the following specifications:
l l l l l
SCUB/SCUF/SCUL supports 40 partitions and 40 sessions. SCUN supports 60 partitions and 60 sessions. One partition supports up to two sessions. Supports enabling and disabling of ANCP partitions (disabled by default). Supports enabling and disabling of ANCP sessions (disabled by default). Supports the ANCP draft version. Versions 00, 01 (default), and 02 are configurable. Versions later than 02 are configured as 02. Supports the following port-based configurations: The partition to which a port belongs. Adds the port that is deleted from a non-0 partition to partition 0 by default. When a port is added to a partition, if the port is up, the topology information about the port is reported to the partition. It is configurable to report port topology information based on service stream or based on port.
Supports setting of the following parameters of an ANCP session: Transmit interval of the SYN/SYNACK packet during the establishment of an ANCP session (transmit interval ranging from 0 to 255 in the unit of 0.1s; 10 by default, that is, 1s) Handshake interval in the ANCP session (handshake interval ranging from 10 to 255 in the unit of 0.1s; 250 by default, that is 25 s) GSMP unicast IP address of the BNG in the ANCP session Whether traps are transmitted when an ANCP session is down or up ANCP VLAN GSMP TCP port ID of the BNG (port ID ranging from 1024 to 65535; 6068 by default) Priority of the ANCP session message, that is, the 802.1p priority of the message (priority levels 0-7; 6 by default) Capability set of the ANCP session (By default, the system supports three capabilities, namely, line topology discovery, L2C OAM, and line configuration. In addition, the multicast CAC and unicast CAC can be supported by the system through configuration, and the default three capabilities can be tailored.)

The ANCP-related standard is under definition by IETF.
20.5.4 Availability
Version Support
Table 20-2 lists the versions that support the ANCP feature. Table 20-2 Versions that support the ANCP feature Product MA5600T/MA5603T BMS Version V800R005C03 and later versions V200R011 and later versions
Issue 01 (2011-10-30)
710
20.5.5 Principle
The MA5600T supports ANCP for implementing the following functions: l l l l l Line topology discovery Line configuration L2C OAM Multicast and unicast CAC Multiple partitioning
Before the above-listed ANCP functions are implemented, an ANCP session needs to be set up between the BNG and the AN.
Setting Up an ANCP Session

Figure 20-5 shows the process of setting up an ANCP session and negotiating the capabilities between the AN and the BNG. Figure 20-5 Setting up an ANCP session
AN
BNG
TCP Connection Established Ancp session established Access-line discovery Line configuration L2C OAM Multicast
The process of setting up an ANCP session is as follows: 1. On the AN side, pre-configure the ANCP session IP address and TCP port ID of the BNG and enable ANCP through the CLI. Then, the AN actively sends a request to the BNG for establishing a TCP connection (the BNG is the server and the AN is the client). After the TCP connection is successfully established, adjacency is formed between the AN and the corresponding BNG. After the capabilities are negotiated, the ANCP session is successfully set up. If the local end finds that the remote end does not support a certain capability, the local end disables this capability and negotiates with the remote end again until both ends have negotiated the capabilities supported by both ends.
2.
Issue 01 (2011-10-30)
3.
Configure capability parameters. Be default, the AN currently supports the capabilities of line topology discovery, line configuration, and L2C OAM. Multicast and unicast CAC can be added to the capabilities through configuration.
After the adjacency is set up, the ANCP protocol enters the maintaining stage. The AN handshakes with the BNG through the ACK message. The interval is the timeout time contained in the message exchanged during the adjacency setup process. If the AN does not receive the ACK message when the timeout time provided by the BNG expires for three times, the session between the AN and the BNG fails. The AN will then reset the adjacency and initiate a connection again.
Line Topology Discovery

The BNG records the actual parameter information about user ports through line topology discovery and thus implements QoS control. After a line is activated and the port rate stabilizes, the ANCP module of the AN queries the parameters (such as upstream/downstream activation rate) of the line and sends the port up message and line parameter information to the BNG. After receiving the line information, the BNG saves the information to local and creates mapping to QoS control policies. After the port is deactivated, the ANCP module sends the port down message to the BNG, as shown in Figure 20-6. Figure 20-6 Line topology discovery
4 PORT_UP message 9 PORT_Down message BNG 1 ANCP session established 2 Access-Line discovery capability advertised 7 Subscriber logs in (PPP/DHCP session) 5 Access loop parameters stored
RG
3 RG turned on, synchronized AN with AN
8 RG turned off, synchronized with AN
6 Set shaping rate, adjust shaping mode
Table 20-3 lists the xDSL line parameters reported by the ANCP module. Table 20-3 Reported DSL line parameters No. 1 Parameter DSL Type Meaning Which DSL type is connected (e.g. ADSL, ADSL2, ADSL2+, SHDSL, or VDSL). This parameter defines the transmission system in use.
Issue 01 (2011-10-30)
712
No. 2 3
Parameter DSL Link State Actual data rate: UPstream and DOWNstream Attainable Data Rate: UPstream and DOWNstream Minimum Data Rate Maximum Data Rate Maximum Interleaving Delay Actual Interleaving Delay Minimum-Net-Low-Power-DataRate-Upstream Minimum-Net-Low-Power-DataRate-Downstream Access Loop Encapsulation
Meaning Line/Port up (Showtime), line/port down (idle or silent) Actual data rate upstream and downstream of a synchronized DSL link Maximum data rate which can be achieved Minimum data rate desired by the operator in bit/s (up/down) Maximum data rate desired by the operator in bit/s (up/down) Maximum one-way interleaving delay Value in milliseconds which corresponds to interleaver setting Minimum data rate upstream desired by the operator during the low power state (L1/L2) Minimum data rate downstream desired by the operator during the low power state (L1/L2) The link protocol type and the PVC encapsulation of the DSL link
4 5 6 7 8 9
10
11
The port up or port down message is uniquely identified by the line ID. The format of the ANCP line ID is configurable. It is recommended to set the format of the ANCP line ID to be consistent with that of DHCP option 82 and PPPoE+ messages. At the same time, the format of the ANCP line ID must be the same as that on the BNG because the BNG creates mapping between user and line according to line ID and user name. The ANCP module can report the port up or port down message in two modes: based on port or based on service stream. l In the port-based mode, if SPLABEL (configured by running the raio-format command) is not configured in the line ID, the following information is reported when the port is up or down: Message in the default format (VPI=0, VCI=32) if the PVC or CVLAN is not specified Specified value if the PVC or CVLAN specified exists l If the port-based mode, if SPLABEL (configured by running the raio-format command) is configured in the line ID, the following situations occur when the port is up or down: The topology information is not reported if the PVC or CVLAN specified does not exist. The specified value is reported if the PVC or CVLAN specified exists.
In the service-stream-based mode, when a port goes up or down, messages are reported for all service streams of the port. When the status of a service stream changes, a message is reported for this service stream.
After the ANCP session fails and is re-established, the AN reports the stable line parameters and port status information, such as port UP or port DOWN, to the BNG.
Line Configuration
Most xDSL user parameters are static data. When user service parameters need to be modified, they need to be configured again from the ISP to the access device in an end-to-end manner. Using the ANCP protocol can avoid a complicated exchange process. The line configuration function is applicable to the self-service customized services. The BNG is required to be able to obtain access line parameters directly from the policy server or RADIUS server and support automatic network update. A precondition is that a copy of line profile parameters of the AN must be saved on the policy server or RADIUS server. Figure 20-7 shows the process of line parameter modification in a service update. Figure 20-7 Service update
infoX SSS Portal Policy server server 3-Business logic
RADIUS server
2-Service on demand 1-Subscriber logs in (PPPoE/DHCP session) PC STB RG AN
4-Change of authorization
TV Phone
BNG 5-Line configuration message
VoD server
Softswitch
The process of line parameter modification in a service update scenario is as follows: 1. 2. 3. An ANCP session is established between the AN and the BNG, and a user connects to the BNG. The user orders the required service on the portal server. The portal server and the policy server (through the COPS protocol) or the RADIUS server (through the RADIUS protocol) issues the line ID and the required profile (line profile) name to the BNG. Specific parameters of the profile are already defined on the AN. The BNG issues the received line ID and profile name to the AN through the ANCP protocol. According to the line ID, the AN learns the subrack/slot/port information corresponding to the profile. According to the profile name, the AN knows about the profile to be configured
4. 5.
Issue 01 (2011-10-30)
on the port. The AN then uses the new profile to activate the user port to implement the customized service.
NOTE
If a line has multiple line profiles, the ANCP supports the configuration of only the profile relevant to the line activation rate.
L2C OAM
The ANCP L2C OAM function can implement the connectivity test between the BNG and the RG. The implementation of the L2C OAM function mainly involves the RG, AN, and BNG, as shown in Figure 20-8. Figure 20-8 L2C OAM
3 L2C OAM message
4 Send OAM F5 ete loopback cell AN RG 1 ANCP session established
BNG
5 echo OAM F5 ete loopback cell
2 ANCP capability advertised
6 echo L2C OAM message
L2C OAM in the ADSL and VDSL ATM modes: l The AN receives the L2C OAM message issued from the BNG and obtains the loopback test port information and the number of loopback cells to be sent (32 by default if a value is not specified). Then, the AN generates loopback cells and sends the cells to the RG.
NOTE
The number of loopback cells ranges from 1 to 32. If the number of loopback cells exceeds 32, the AN discards the excess cells.
After receiving the loopback response from the RG, the AN obtains the test result. The test result includes the test port information and the loopback result (success or failure). The AN then reports the test result to the BNG through a message.
In the VDSL PTM mode, the AN sends response messages to the BNG according to the port status. If the VDSL port is up, the AN responds with a success message; if the VDSL port is down, the AN responds with a failure message.
Multicast and Unicast CAC

ANCP connection admission control (CAC) and BTV CAC are the same in terms of concept. They are both a protection mechanism for managing the bandwidth of the video programs. The ANCP multicast CAC and unicast CAC mainly involve three devices: AN, BNG, and resource admission control subsystem (RACS). The AN and the BNG are connected through ANCP, and the BNG and the RACS are connected through COPS interfaces. Video bandwidth: Total video bandwidth of AN users = Multicast program bandwidth of the users + Unicast VoD bandwidth of the users l l User multicast bandwidth CAC is implemented on the AN. User unicast VoD bandwidth CAC is implemented on the RACS (the policy server on the Figure 20-9).
Video bandwidth waterline mechanism: The AN introduces a video bandwidth waterline mechanism to dynamically adjust the video bandwidth between the AN and the RACS. In this mechanism, the total video bandwidth of users is compared to a container. Through the video bandwidth waterline mechanism, the waterline in the container can be upshifted/ downshifted to dynamically adjust the bandwidth resources for multicast programs and the bandwidth resources for unicast VoD programs. When the bandwidth resources for multicast programs are insufficient, the bandwidth resources for unicast VoD programs can be requested for multicast programs. The same is true for unicast VoD programs. This mechanism enhances user experience with program demanding. Video bandwidth waterline data update: When the AN or the RACS applies to each other for bandwidth, the applicant starts a timer (set to 500 ms). If the applicant does not receive a response after the timer times out, the AN deletes the IGMP join message of the corresponding user from the buffer and returns a program demand failure to the user. At the same time, the AN or the RACS actively queries each other about the video bandwidth information and updates their own video bandwidth waterline data according to the waterline data of the peer. If the query about the video bandwidth information fails, the AN or the RACS does not update the video bandwidth waterline data. ANCP feature and BTV feature: The relationship between the ANCP multicast CAC feature and the BTV multicast CAC feature is as follows: l l When BTV multicast CAC is not enabled, the AN cannot implement multicast CAC regardless of whether ANCP multicast CAC is enabled or not. The video bandwidth between the AN and the RACS can be dynamically adjusted only when BTV multicast CAC and ANCP multicast CAC are enabled.
Multicast CAC
Figure 20-9 shows the application scenario of multicast CAC.
Figure 20-9 Application scenario of multicast CAC

NMS Policy server
DHCP server
1 2 Resource ACK ANCP
SOAP 3 Head end video server Multicast stream
COPS
Resource request 4 TE TUNNEL ME NPE
TV
AN
BNG NPE
The message exchange process of multicast CAC is as follows:

AN BNG RACS
RG
1 2
User goes online. Video bandwidth water line of AN user=Bm IGMP Join BTV CAC OFF, a failure is returned.
Reports port up.
Reports port up.
Issues user total video bandwidth Ba and user multicast bandwidth Bm.
IF BTV CAC ON, and multicast program bandwidth <Available multicast bandwidth
IF BTV CAC ON & ANCP CAC OFF Multicast program bandwidth>Available multicast bandwidth, a failure is returned
IF BTV CAC ON & ANCP CAC ON Multicast program bandwidth>Available multicast bandwidth, applies for unicast VoD bandwidth Unicast bandwidth is sufficient: application succeeds Unicast bandwidth is insufficient: application fails
User joins multicast group AN bandwidth waterline=Bm+ Applied bandwidth
User cannot join multicast group AN bandwidth waterline remains unchanged.
Unicast CAC
Figure 20-10 shows the application scenario of unicast CAC.
Figure 20-10 Application scenario of unicast CAC

Portal server
1 Policy server SOAP 2 DHCP server

4
VoD request
NMS
Resource request
Re so AC urce K
COPS
3 Policy
3 Policy
5 ANCP
VoD stream
Head end video server
ME
TV AN BNG TE TUNNEL
NPE
NPE
After detecting that a user goes online, the RACS actively configures the user video bandwidth information for the AN and updates the user video bandwidth waterline on the AN according to the user video bandwidth information on the RACS. The user video bandwidth waterline on the RACS equals the user unicast VoD bandwidth. If the total video bandwidth equals the unicast VoD bandwidth, the RACS manages all the video bandwidth for the user. In this case, the multicast bandwidth of the user is 0. The message exchange process of unicast CAC is as follows: 1. 2. When the user demands a unicast program through the portal interface, the demand information is transmitted to the VoD server through the data channel. The VoD server requests unicast CAC from the RACS. The RACS compares the unicast VoD bandwidth requested by the user with the available unicast VoD bandwidth of this user. l If the unicast VoD bandwidth requested by the user is smaller than the available unicast VoD bandwidth, the user is allowed to demand this unicast VoD program and the available unicast VoD bandwidth is updated on the RACS. After the update, the available unicast VoD bandwidth of the user = Pre-update unicast VoD bandwidth of the user - Unicast VoD bandwidth requested by the user. l If the unicast VoD bandwidth requested by the user exceeds the available unicast VoD bandwidth, the RACS needs to apply to the AN for multicast bandwidth resources through the extended ANCP message. 3. The ANCP module of the AN will receive the bandwidth application message. If the multicast CAC of the ANCP module is disabled, the AN responds with a request failure message. If multicast CAC is enabled on the ANCP module, the ANCP module checks whether the available multicast bandwidth of the user is sufficient for the bandwidth requested by the unicast user. l If the remaining available multicast bandwidth is sufficient, the ANCP module grants the multicast bandwidth to the unicast user and then sends an ANCP message to the
RACS to notify the success, and at the same time updates the AN video bandwidth waterline. The bandwidth requested by the RACS this time needs to be deducted from the video bandwidth waterline and also needs to be deducted from the remaining available multicast bandwidth of the user. l If the remaining available multicast bandwidth is insufficient, applying for the multicast bandwidth fails. In this case, the ANCP module sends an ANCP message to the RACS to notify the failure. 4. The RACS processes the bandwidth application results accordingly. If the application is successful, the RACS updates the unicast bandwidth on the RACS (the original unicast bandwidth + the successfully requested bandwidth this time), and returns the unicast CAC result to the VoD server. The VoD server processes the unicast CAC result. If the VoD server processes the unicast CAC result successfully, demanding the unicast program continues. Otherwise, demanding the unicast program is stopped.
NOTE
5.
If the user stops demanding VoD programs, the VoD server sends the RACS a message indicating that demanding VoD programs has stopped. In this case, the RACS updates the unicast bandwidth on the RACS (the unicast bandwidth + the bandwidth of this VoD program).
Multiple Partitioning
The ANCP multiple partitioning function enables different xDSL ports to the grouped in different ANCP partitions. Different partitions are managed by different BNGs in order to support wholesale service. Generally, each BNG is managed by a respective ISP. One xDSL port can belong to only one partition. As shown in Figure 20-11, user 1 and user 2 are managed by BNG 1, and user 3 by BNG 2. In other words, user 1 and user 2 belong to the same partition. and user 3 belong to a different partition. Figure 20-11 Network topology of ANCP multiple partitioning
NMS BNG1 User1 AN RG User2
SN
MP
ANCP
eg. MA5200G
ANCP RG User3 BNG2 eg. MA5200G
Issue 01 (2011-10-30)
719

Acronym/ Abbreviation ANCP BNG BRAS Full Spelling Access Node Control Protocol Broadband network gateway Broadband remote access server
20.6 Environment Monitoring

In general, environment monitoring involves environment parameters monitoring and power monitoring. Environment parameters monitoring refers to monitoring of the environment parameters that might cause failure or damage to the system. Power monitoring refers to monitoring of the power supply system.
20.6.1 Introduction
Definition
In general, environment monitoring involves environment parameters monitoring and power monitoring. l Environment parameters monitoring refers to monitoring of the environment parameters that might cause failure or damage to the system. The parameters include: temperature, humidity, door status sensor, water, smog, and main distribution frame (MDF). Power monitoring refers to monitoring of the power supply system, which involves: mains input, DC distribution, rectifier module, and battery.
Externally, to implement the environment monitoring, connect a serial port cable between the monitoring serial port on the MA5600T/MA5603T and the communication serial port on the monitored device. In this way, on the MA5600T/MA5603T, you can directly monitor its environmental conditions based on the proprietary protocol. l l l You can directly monitor the status of the power supply parameters, fans, external batteries, and some built-in environment monitoring parameters. If external sensors are connected, you can query the functions provided by the sensors such as the ambient temperature and humidity, buzzer, and cabinet lamp. You can also modify some configuration parameters such as the alarm thresholds of the environment parameters and the control parameters of the power and batteries. In this way, the monitored devices can work according to your requirements.
Purpose
The purpose of the environment monitoring is to monitor the running of the MA5600T/ MA5603T at all times. This helps to detect any fault as soon as possible, and thus to meet the requirement for a stable telecommunication network.
The MA5600T/MA5603T supports the following environment monitoring specifications: l l Monitoring of fans Monitoring of the H801ESC
20.6.3 Availability
License Support
The environment monitoring feature is the basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Version Support
Hardware Support
l l The fan tray is required for monitoring the fans. The H801ESC board is required for monitoring the ESC.
20.6.4 Principle
The environment monitoring of the MA5600T/MA5603T is implemented in upper device/lower device mode. That is, an upper device manages multiple lower devices, as shown in Figure 20-12. The upper device communicates with the lower devices based on the master/slave protocol. A typical configuration consists of an ESC and multiple fans. Figure 20-12 Master/slave communication in the environment monitoring
Upper device
Lower device 1
Lower device N
Issue 01 (2011-10-30)
721
The upper device herein refers to the control board of the MA5600T/MA5603T, and the lower device herein refers to a monitoring board or subrack that has the monitoring function, namely, the environment monitoring unit (EMU). The upper device interacts with the lower devices as follows: l l l The upper device manages and maintains the status of the lower devices. A lower device detects through its own hardware interface the external data, processes the data, and reports it to the upper device. The upper device translates the user commands, and then forwards the translated commands to the lower devices. Then, the lower devices take the corresponding actions.
EMU
To implement the environment monitoring function, make sure that the environment devices are available. The environment monitoring devices include: l l An independent board, such as the H801ESC board. A monitoring module built in other devices such as a fan monitoring tray.
The devices that are used for monitoring are called the environment monitoring units (EMUs) regardless of whether they are independent or built in other entities. An EMU must have a monitoring processing board and the interface for communication with the host. The EMUs in the MA5600T/MA5603T system include: l H801ESC The H801ESC EMU adopts the built-in sensors and provides the interface for extended sensors. In this way, more environment parameters and power supply parameters can be monitored. The H801ESC EMU does not support the battery management. l FAN It is the fan tray that has the monitoring function. That is, a monitoring board is built in the fan tray. The FAN EMU can monitor only simple built-in analog and digital parameters. It neither provides the interface for extended sensors, nor supports the power monitoring. Therefore, it cannot monitor the batteries.
Slave Node
Environment monitoring is implemented in master/slave communication mode. In this mode, a lower device (slave node device) must have a unique ID. Otherwise, in point-to-multipoint or multipoint-to-multipoint communication mode, the communication is confused. The unique ID of a lower device is called a slave node number (or a salve node address), which is determined by the hardware (similar to the MAC address of the network interface card). In general, a lower device provides the DIP switches that are used for adjusting the slave node number. Make sure that the slave node numbers of all the lower devices corresponding to an upper device are different. Otherwise, the upper device fails to communicate with the lower devices.
Issue 01 (2011-10-30)
722
Analog Parameters
An analog parameter is a successive parameter, such as temperature, voltage and current. The analog parameter monitoring interface generally uses the analog sensor, namely, the device that detects the analog parameters in real time. The analog sensor has the following attributes: upper alarm threshold, lower alarm threshold, upper measurement threshold, lower measurement threshold, sensor type and unit, current value, and current status. l The upper and lower alarm thresholds are used to determine whether an alarm is generated for an analog parameter. The analog parameter is in the normal state only when it meets the following criteria: Lower alarm threshold <= Current value <= Upper alarm threshold Where, : indicates the hardware tolerance. l The upper and lower measurement thresholds indicate that each sensor has its measurement range. The measurement range of some sensors is adjustable. The measurement results vary with the measurement range. The upper and lower alarm thresholds must be within the measurement range. Sensor type: Generally, sensors consist of current sensors and voltage sensors. This parameter is mandatory when you configure the analog parameters. Unit: You need to define the unit based on the object detected by the sensor and the actual precision of the sensor. Current value and current status: The analog sensors can report the monitored values of various analog parameters in real time, and generally can report the status of a parameter (too high, too low, or normal).
l l l
For an EMU, analog parameters are divided into the built-in parameters and the extended parameters. l l The built-in analog parameters are fixed and unchangeable. For example, the temperature and humidity sensors are fixed on the H801ESC board. The extended analog parameters can be changed. That is, you can configure the analog sensors to meet your requirements.
Digital Parameters
Compared with an analog parameter, a digital parameter is a discrete value or a state value. A digital sensor has only two values: normal or faulty. A digital sensor tests the state value by comparing the low level and the high level. The digital sensor has the following attributes: alarm level, significant level, sensor type, and current status. l Alarm level: When the level of a digital parameter equals the alarm level, the digital sensor generates an alarm. If the alarm level of the digital sensor is set to the high level, when the monitored digital parameter becomes the high level, the sensor generates an alarm. When the digital parameter becomes the lower level, no alarm is generated. Significant level: It is on the contrary to the alarm level. That is, when the level of a digital parameter equals the significant level, the digital sensor does not generate an alarm. Sensor type: Generally, sensors consist of current sensors and digital sensors. This parameter is mandatory when you configure the digital parameters.
l l
Issue 01 (2011-10-30)
Current status: It is the state value detected by the digital sensor.
For an EMU, the analog parameters can also be divided into the built-in parameters and the extended parameters. l l The built-in digital parameters are fixed and unchangeable. For example, the door status and MDF sensors are fixed on the H801ESC board. The extended digital parameters can be changed. That is, you can configure the digital sensors to meet your requirements.
20.7 Power Saving and Maintenance

This topic describes the power saving feature of the system from two aspects: stepless speed adjustment of the fan and power cutoff of the board. It also describes the maintenance feature of the system from two aspects: power cutoff of the board and recording the model and running information for the fan and power module.
20.7.1 Overview of the Power Saving and Maintenance Feature

The power saving feature is related to the following two items: l l The fan rotating speed is precisely controlled based on the temperature on the parts (boards), and the fans do not rotate at a constant speed, thus reducing the power consumption. The power of the board is cut off to reduce the power consumption when the temperature on a board reaches the threshold of danger.
The maintenance feature is related to the following two items: l l The remote board can be manually powered off and then powered on for maintenance, which is similar to the hot plug operation. The model and running information of the fan and power module can be recorded, thus reducing the process cost for preparing the spare parts of multiple versions.
20.7.2 Power Saving

l The fans for the subrack of the MA5600T/MA5603T do not rotate at a constant speed. They automatically implement the stepless speed adjustment according to the temperature inside the subrack detected by the temperature sensor, thus reducing the power consumption. The board of the MA5600T/MA5603T supports power cutoff of the board, thus saving the power. Automatic power cutoff of the board: When detecting that the temperature on a board exceeds the temperature threshold, the system automatically cuts off the power supply of the board, and then powers it on in 15 minutes. Manual power cutoff of the board: When the port on the board is not configured with any service, you can manually cut off the power of the board through the CLI or NMS
to reduce the power consumption. You can also re-power power on the board again through the CLI or NMS.
NOTE
When you manually cut off the power of a board that is providing a service, the system prompts that a service is running on the board and the service will be interrupted if the power is cut off. You need to determine whether to cut off the power of the board.
Purpose
The purpose of the power saving feature is to reduce the power consumption and heat consumption of the system. l The rotating speed of the fans is adjusted according to the temperature on the key components inside the subrack instead of the environment temperature. The rotating speed of the fans is more precise, and thus the optimal power saving effect is achieved. Certain boards of the MA5600T/MA5603T are equipped with the temperature sensor, which supports querying the temperature on the board, automatic power cutoff of the board against high temperature, and manual power cutoff of the board, thus reducing the power consumption.
Specifications
None
Limitations
l l The fans on the subrack support the stepless speed adjustment. The control board, power board, and GIU upstream board do not support power cutoff of the board.
20.7.2.2 Availability
l Hardware Support The following boards support automatic power cutoff of the board against high temperature: xDSL boards: H80BCAME, H80BVDPM, H80BVDPE, H802ADKM, H802VDJM, H80ASHLM, H808ADLF, H808ADLE, H805VDSF, H805VDSA, H805VDMF, H805ADPD, H802VDNF, H80BADPE xPON boards: H801GPBC, H802GPBD, H802EPBC, H805GPBD Other boards: H801ASPB, H808ASPB, H801OPFA, H802OPGD, H801SPUA, H801SPUB, H801CSPA, H801TOPA, H802EDTB l License Support The power saving feature is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service.
20.7.2.3 Principle
This topic describes the working principle of the power saving feature.
Stepless Speed Adjustment of the fans on the Shelf

The working principle of the automatic stepless speed adjustment of the fans is as follows:
1. 2.
The system queries the temperature on all the boards in the subrack every 10 minutes, and directly omits the boards that do not support querying the temperature. If the queried temperature meets the speed adjustment condition, the system issues the rotating speed adjustment command and the corresponding duty ratio to the fans on the subrack to adjust their rotating speed. Table 20-5 and Figure 20-13 show the mapping between the speed adjustment of the fans and the temperature control point of the boards. Table 20-5 Mapping between the speed adjustment of the fans and the temperature control point of the boards Temperature Interval (, low-temperature alarm threshold) Temperature Level Level 1 Fan Speed Adjustment or System Joint Change l The board reports a lowtemperature alarm. l Speed lowered for one level [low-temperature alarm threshold, low-temperature alarm recovery threshold) [low-temperature alarm recovery threshold, temperature threshold for the speed to be lowered for one level) Level 2 Speed lowered for one level
Level 3
l The board reports a lowtemperature clear alarm. l Speed lowered for one level
[temperature threshold for the speed to be lowered for one level, temperature threshold for the speed to be increased for one level) [temperature threshold for the speed to be increased for one level, temperature threshold for full speed) [temperature threshold for full speed, high-temperature alarm recovery threshold)
Level 4
The fan remains its speed.
Level 5
Speed increased for one level l The board reports a high-temperature clear alarm. l Full speed
Level 6
[high-temperature alarm recovery threshold, high-temperature alarm threshold) [high-temperature alarm threshold, high-temperature shutdown threshold) [High-temperature shutdown threshold, +)
Level 7
Full speed
Level 8
l The board reports a high-temperature alarm. l Full speed
Level 9
High-temperature shutdown
Issue 01 (2011-10-30)
726
Figure 20-13 Mapping between the speed adjustment of the fans and the temperature control point of the boards
Action
Hig h -te
mp
Hig h-t e
Hig h
sh utd mp ow n Fu erat ll s ure pe ed alar m; Fu ll s pe ed
era t
ure
- te mp
Lo w Sp -tem ee d l pera ow tur er e e c d f lea or r on alar e m L3 lev ; L1 L2S el pe e for d lo L Sp ow-t on wer ee em el ev ed dl el ow pera e r e tu r df ea l or on arm; el ev el
Sp ee for d inc on rea el ev sed el Sp ee dr em ain s
era t Fu ure r ll s es pe um ed e
ala
rm ;
L4
L5
L6
L7
L8
L9 Temperature Level
3.
The rotating speed of the fans on the subrack is adjusted to the expected value.
Automatic/Manual Power Cutoff of the Board

When the temperature on a board reaches the threshold of danger or the board is not configured with any service, measures should be taken to reduce the power consumption. Currently, the power of the board is cut off to reduce the power consumption. Figure 20-14 shows the power saving principle of the automatic/manual power cutoff of the board.
Issue 01 (2011-10-30)
727
Figure 20-14 Power saving principle of thee automatic/manual power cutoff of the board
BRAS
NMS
Remote maintenance terminal
Fan tray 21 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 G I U 20 G I U
22
The power saving principle of the automatic/manual power cutoff of the board is as follows: 1. When detecting that the temperature on a board exceeds the temperature threshold, there are three phases: Full speed, The board reports a high-temperature alarm, and Hightemperature shutdown. See Table 20-5.
NOTE
2.
20.7.3 Maintenance
Power Power
0
S S C C U U
Service board
Service board
Service board
Service board
GPIO
Temperature sensor Power supply of the board
The control board, power board, and GIU upstream board do not support power shutdown upon excessively high temperature, but the power supply to the LSW chip on the control board will be shut down.
When the system detects that the temperature on a board is too high or the port on the board is not configured with any service, you can manually cut off the power of the board through the CLI or NMS to reduce the power consumption. After powering off the board, you can power it on again through the CLI or NMS. l In case of high temperature, when you run a command to manually cut off the power of a board that is providing a service, the system prompts that a service is running on the board and the service will be interrupted if the power is cut off. You need to determine whether to cut off the power of the board. l In the case that the port on a board is not configured with any service, the system does not display any message when you run a command to manually cut off the power of the board. l When a command is issued from the NMS to cut off the power of a board, the system directly cuts off the power of the board in any case.

l The MA5600T/MA5603T supports power cutoff of the board, and can be forcibly powered off/on even when it is down or faulty. This is like remote hot plug of the board, meeting the requirement of remote maintenance. The MA5600T/MA5603T supports recording the model and running information for the fans on the subrack and the power module. When a fan on the subrack or the power module is faulty, the model and running information of the faulty part can be queried. In this manner, the maintenance engineer can bring the correct spare parts to the field and analyze the cause of the fault according to the running information.
Purpose
The purpose of the maintenance feature is to reduce the human cost for multiple site visits of the maintenance engineer and the process cost of preparing spare parts of multiple versions. l The maintenance engineer can cut off the power of the faulty board through the CLI or NMS in the CO instead of removing and inserting the board on site, thus recovering the service. When a fan on the subrack or the power module is faulty, the maintenance engineer can query the information about the faulty part and the running information in the last three times through the CLI in the CO, thus preparing the correct spare parts, reducing the cost of preparing spare parts of multiple versions, and analyzing the cause of the fault according to the running information.
Specifications
None
Limitations
l The control board, power board, and GIU upstream board do not support power cutoff of the board.
20.7.3.2 Principle Manual Power Cutoff of the Board

The maintenance principle of the manual power cutoff of the board is as follows: 1. When a board is down or faulty: l Before: The maintenance engineer needs to go to the site and power on the board again on site by removing and inserting the board. l Now: The maintenance engineer needs not go to the site. Instead, the maintenance engineer can power on the board again by forcibly cutting off the power of the board through the CLI or NMS in the CO. 2. The manual power cutoff of the board reduces the human cost on multiple site visits of the maintenance engineer.
Issue 01 (2011-10-30)
Recording the Model and Running Information for the Fans on the Shelf and the Power Module
The current status analysis for the maintenance of the fans on the subrack and the power module is as follows: l l When a fan on the subrack or the power module is faulty, the model and running information of the faulty module are not recorded on the host. The fans on the subrack and the power module have multiple models, and the maintenance engineer needs to prepare multiple types of modules for the site, which increases the preparation cost and process cost. The fans on the subrack and the power module in a site become faulty for multiple times, but there is no corresponding information for fault analysis.
The system records the model and running information for the fans on the subrack and the power module as follows: 1. When the fans on the subrack and the power module work in the normal state, the system records the current system time and the running information in the last three times. The following points are included: l System time (Systime) l EMU type (EMU type) l EMU name (EMU name) l Fan type (FAN type) l Software version (Soft ver) 2. When a fan on the subrack or the power module is faulty, you can run a command to query the detailed information about the fan or the power module. l The model of the fan or power module to be replaced can be precisely recognized, which effectively saves the preparation cost of the maintenance engineer. l The running information can be used to analyze the fault and find the root cause, thus reducing the fault possibility of the fan and the power module.
20.7.4 Glossary
Table 20-6 Glossary of the terms related to the power saving and maintenance feature Term Stepless speed adjustment Duty ratio Description Adjusts the rotating speed of the fans on the subrack according to the duty ratio. The duty ratio is 100% when the fans rotate at full speed, and 0 when the fans stop. Describes the rotating speed of the fans on the subrack. The duty ratio is 100% when the fans rotate at full speed, that is, the fans rotate at 100% of the velocity.
20.8 ONT DHCP Simulation

In FTTH scenarios, when services (such as IPTV and VoIP) obtaining IP addresses by DHCP fail, users can perform DHCP simulation on the ONT to quickly locate the fault.
20.8.1 Introduction
Definition
In DHCP simulation, IP address application from the DHCP server is performed by simulating a DHCP client on the device between the DHCP client and the DHCP server instead of by using a real client. The DHCP simulation tests network connectivity between the device and the DHCP server and verifies the DHCP configurations on the DHCP relay, DHCP proxy, and DHCP server. In ONT DHCP simulation, IP address application from the DHCP server is performed by simulating a DHCP client on the ONT instead of by using a real client. The DHCP simulation tests network connectivity between the ONT and the DHCP server and verifies the DHCP configurations on the DHCP relay, DHCP proxy, and DHCP server. The common DHCP clients include the STB, VoIP service terminal, and PC obtaining the IP address by DHCP.
Purpose
An FTTx network covers a large area and the network devices are geographically dispersed. Carriers usually assign different OM personnel to different network layers. After receiving a fault reported by a user, the carrier determines the fault scope and then assigns the corresponding OM personnel. This requires the FTTx system to support remote fast fault locating capabilities. The following uses the IPTV service in the FTTH scenario as an example to describe DHCP simulation. The FTTH IPTV service involves multiple devices crossing different networks between STBs and the IPTV server, as shown in Figure 20-15.
NOTE
In the figure, the OLT serves as a DHCP relay and the BRAS serves as the DHCP server. In an actual network topology, the DHCP server can be independently deployed or integrated on a network device such as router.
Figure 20-15 Network topology of the FTTH IPTV service

NMS BRAS
ONT STB
Optical splitter
OLT
IPTV server
TV
Router
Router
STB TV
When the IPTV service fails, the faulty section of the service route needs to be quickly located, which brings the following two challenges:
Fast fault locating: In DHCP mode, if the STBs fail to obtain the IP address, the network between the STBs and the BRAS fails. However, the network between STBs and the BRAS covers a large area, including the network between STBs and the ONT, the network between the ONT and the OLT, and the network between the OLT and the BRAS. As such, fast fault locating on the live network is difficult. Remote checking of network connectivity between STBs and the IPTV server: In DHCP mode, if the STBs obtain the IP address, network connectivity between the STBs and the BRAS is normal. If the user fails to watch a program, network connectivity between STBs and the IPTV server needs to be checked. The STB is at user's home and the IPTV server is maintained by the video service provider; therefore, a carrier cannot directly perform operations on the STB and IPTV server.
To address the two issues, DHCP simulation can be performed on the ONT and ping operation can be performed on the IPTV server by using the OLT CLI or the NMS. This achieves remote fault locating and service acceptance. l By performing DHCP simulation on the ONT, users can verify: Whether the network between the ONT and the BRAS is functioning properly. Whether the DHCP configurations on the BRAS are correct. l After successful DHCP simulation, the ONT can ping the IPTV server by using the STB's IP address obtained by DHCP simulation to check network connectivity between the ONT and the IPTV server.
l l l DHCP simulation can be performed on a maximum of 16 registered and online ONTs under the same MA5600T/MA5603T. Only one DHCP simulation can be performed on a Huawei ONT each time. Each DHCP simulation instance can ping up to five IP addresses of the specified devices such as IPTV server.

The reference standards and protocols related to ONT DHCP simulation are as follows: l l RFC2131: Dynamic Host Configuration Protocol RFC1533: DHCP Options and BOOTP Vendor Extensions
20.8.4 Availability
Related NEs
Instructions for ONT DHCP simulation can be issued in the following modes. Table 20-7 lists the modes and related NEs. Table 20-7 Modes for issuing instructions and related NEs Mode for Issuing Instructions OLT CLI
Issue 01 (2011-10-30)
Related NE ONTs and OLTs supporting ONT DHCP simulation
732
Mode for Issuing Instructions NMS
Related NE ONTs, OLTs, and NMS supporting ONT DHCP simulation
License Support
ONT DHCP simulation is an optional feature of FTTx V100R007, and the corresponding services are controlled by the license.
Version Support
Table 20-8 lists the versions supporting ONT DHCP simulation. Table 20-8 Version support Product ONT Version l V100R005C00 and later versions l V100R005C01 and later versions l V200R005C00 and later versions l V200R005C01 and later versions l HG850a V100R001C07 and later versions MA5600T/ MA5603T U2000 V800R010C00 and later versions V100R006C00
Feature Dependency
l The configured DHCP simulation parameters must conform to the carrier's network plan. If parameters do not conform to the network plan, DHCP simulation may fail and the simulation results will not reflect the actual link connectivity. The MAC address used for DHCP simulation must be unique in the service VLAN. Using a unique MAC address prevents simulation instances from interfering with each other and ensures that users not encountering the fault can still use the service properly. The actual MAC address of the DHCP client is recommended for DHCP simulation to truly simulate the packets sent by the DHCP client. Simulation results need to be queried within 210s after simulation starts. If the query operation is performed after 210s, the results cannot be queried because simulation times out and the results are deleted. DHCPv4 simulation is supported and DHCPv6 simulation is not supported. DHCP simulation and PPPoE simulation cannot be concurrently performed on an ONT. During the simulation, the WAN port can not be added, modified or deleted from an ONT. Services of the simulated user may be affected during the simulation because DHCP simulation occupies ONT resources.
l l l l
Issue 01 (2011-10-30)
DHCP simulation can only locate the faulty section of a service route. To determine the cause of the fault, the fault symptom and network topology need to be used together for analysis.
Hardware Support
ONTs, OLTs, and NMS supporting ONT DHCP simulation need to be used together to implement this feature. All PON boards of the OLT support ONT DHCP simulation.
20.8.5 Principle
This topic uses the FTTH IPTV service as an example to describe the principle of locating an IPTV service fault using ONT DHCP simulation. The common modes of providing the IPTV service are video on demand (VoD) and Internet Group Management Protocol (IGMP). The two modes have the following prerequisites: l l The STB can obtain the IP address. The link between the STB and the IPTV server is connected.
Figure 20-16 shows the scenario for ONT DHCP simulation and the ping operation on the IPTV server.
NOTE
In the figure, the OLT serves as a DHCP relay and the BRAS serves as the DHCP server. In an actual network topology, the DHCP server can be independently deployed or integrated on a network device such as router.
Figure 20-16 Scenario for ONT DHCP simulation and the ping operation on the IPTV server
NMS
STB TV ONT STB Optical splitter OLT IPTV server
TV
Router BRAS
Router
ONT DHCP simulation Ping operation on the IPTV server
ONT DHCP simulation: 1. 2. On the ONT, a DHCP client is simulated and functions in the place of an STB. The DHCP client performs DHCP dialup to the BRAS. If DHCP dialup is successful, the link between the ONT and the BRAS is reachable and the DHCP dialup process from the ONT to the BRAS is normal. If the STB fails to obtain the IP address but ONT DHCP simulation is successful, the DHCP dialup process from the
Issue 01 (2011-10-30)
ONT to the BRAS is normal. In this case, the faulty section of the service route is narrowed down from the network between the STB and the BRAS to the network between the STB and the ONT. 3. If DHCP dialup fails, the DHCP dialup process from the ONT to the BRAS fails. This may be because the link between the ONT and the BRAS is unreachable or DHCP configurations on the BRAS are incorrect.
Ping operation on the IPTV server: 1. 2. 3. The IP address obtained by ONT DHCP simulation is used as the source IP address of the STB. This IP address is used for pinging the IPTV server from the ONT. If the ping operation is successful, the link between the ONT and the IPTV server is reachable. If the ping operation fails, the link between the ONT and the IPTV server may be unreachable. However, the link between the ONT and the BRAS is reachable because the DHCP dialup was successful. In this case, the faulty section of the service route is possibly narrowed down to the link between the OLT and the IPTV server.
The ping operation on the IPTV server can be performed only after DHCP simulation is successful. If DHCP simulation fails, the ONT fails to obtain the IP address that will be used to ping the IPTV server.
Issue 01 (2011-10-30)
735
21 Ethernet OAM
21
About This Chapter
21.1 Introduction 21.2 Reference Standards and Protocols
Ethernet OAM
Operations, administration and maintenance (OAM) is a method of monitoring and diagnosing network faults.
21.3 Ethernet CFM OAM Ethernet connectivity fault management (CFM) operation, administration and maintenance (OAM) provides a method for end-to-end (E2E) fault detection. With this method, Ethernet link connectivity can be monitored and Ethernet link faults can be located. 21.4 Ethernet EFM OAM Ethernet EFM OAM provides a mechanism for monitoring links. It can serve as a complement to the higher layer applications. This topic provides an introduction to this feature, and describes the availability and working principle of this feature. 21.5 Glossary, Acronyms, and Abbreviations
Issue 01 (2011-10-30)
736
21 Ethernet OAM
21.1 Introduction
Table 21-1 Differences between Ethernet CFM OAM and Ethernet EFM OAM ETH OAM Type Ethernet CFM OAM Ethernet EFM OAM Standard Compliance IEEE 802.1ag IEEE 802.3ah Purpose Fault detection and diagnosis Link monitoring

Table 21-2 Reference standards and protocols of the Ethernet OAM feature Ethernet OAM Type Ethernet CFM OAM Reference Standards and Protocols l IEEE 802.1ag-2007 VLAN Amendment 5 Connectivity Fault Management l WT-156v17-Straw Ethernet EFM OAM IEEE 802.3ah: Operations, Administration, and Maintenance (OAM)
21.3 Ethernet CFM OAM

Ethernet connectivity fault management (CFM) operation, administration and maintenance (OAM) provides a method for end-to-end (E2E) fault detection. With this method, Ethernet link connectivity can be monitored and Ethernet link faults can be located.
21.3.1 Introduction
Definition
Operation, administration and maintenance (OAM) refers to the methods for monitoring and diagnosing network faults. Ethernet connectivity fault management (CFM) OAM is defined in IEEE 802.1ag to provide an E2E fault detection and diagnosis method for the entire Ethernet.
Purpose
Ethernet is a widely used local area network (LAN) technology. It provides rich bandwidth, features low costs, and supports plug-and-play and multipoint operations. As the application of the Ethernet technology is extending from carrier networks to metropolitan area networks (MANs) and wide area networks (WANs), network management and maintenance becomes
21 Ethernet OAM
increasingly important. Currently, however, Ethernet has no carrier-class management capability and therefore Layer 2 network faults cannot be detected on Ethernet networks. Ethernet CFM OAM supports the following three functions. Function Connectivity check (CC) Loopback (LB) Purpose Monitors connectivity of Ethernet links in real time and reports abnormalities by alarms. l Checks connectivity of the Ethernet link between two devices. l Determines the link interruption location if a link fault occurs. Linktrace (LT) l Obtains the MAC address of the intermediate device along the Ethernet link between two devices. l Determines the link interruption location if a link fault occurs.
The MA5600T/MA5603T supports the following Ethernet CFM OAM specifications: l l The system supports a maximum number of eight maintenance domains (MDs) with IDs ranging from 0 to 7. The levels of objects managed by an MD range from 0 to 7. The larger the value, the higher the level. The MD has three levels: user domain (7-5), service provider domain (4-3), and carrier domain (2-0). The system supports a maximum number of 4096 maintenance associations (MAs) ranging from 0 to 4095. The system supports a maximum number of 4096 maintenance end points (MEPs) with IDs ranging from 1 to 8191. An MD supports a maximum number of 4096 MAs. If an MD is configured with 4096 MAs, no more MAs can be configured for other MDs. An MA supports one local MEP and eight remote MEPs (RMEPs). An MA can be associated only to one VLAN. If an MA is associated to VLAN 0, it indicates that the MA is not associated to a VLAN. A VLAN can contain only one up MEP. The up MEP and down MEP can be created. One port can be configured as the MEP of only one type. The maintenance intermediate point (MIP) can be automatically created. Connectivity check (CC) can be performed on an S-VLAN basis. The interval of sending continuity check messages (CCMs) of an MA can be set to 1s, 10s, 1 minute, or 10 minutes. The default interval is 1 minute. Compared with other boards, SPUA also supports 3.3 ms, 10 ms, and 100 ms. SPUA supports aggregation group switching and protect group switching triggered by CC. The system supports global enabling or disabling of Ethernet CFM. The system supports configuration of MEPs on a protect group basis. The system supports packet statistics query for an MEP.
l l l l l l l l l l
l l l l
Issue 01 (2011-10-30)
21 Ethernet OAM
l l
The system supports configurations of the CCM alarm waiting time and CCM alarm clear time for an MEP. The system supports configuration of a lowest priority for MEP alarms. With this configuration, an MEP reports only the alarms of priorities higher than the lowest priority.
21.3.3 Availability
License Support
Ethernet CFM OAM is an optional feature of the MA5600T/MA5603T and the corresponding service is licensed.
Version Support
Feature Dependency
l l Ethernet CFM OAM is implemented according to the formal IEEE 802.1ag-2007 and is not compatible with Draft6.0. Ethernet CFM OAM partially supports ITU-T Y.1731. That is, Ethernet CFM OAM does not support the functions that are defined in ITU-T Y.1731 but are not defined in IEEE 802.1ag. For aggregated ports, the maintenance end point (MEP) can only be configured on the primary port but cannot be configured on the secondary port. The network-side MEP does not support two VLAN tags. After Ethernet CFM is enabled globally, the MA5600T/MA5603T processes only the Ethernet CFM packets in the maintenance domain (MD) configured on the MA5600T/ MA5603T, but transparently transmits the CFM packets in the MDs with higher priorities.
l l l
Hardware Support
Table 21-4 lists the boards supporting Ethernet CFM OAM. Table 21-4 Boards supporting Ethernet CFM OAM Board Type Control board Board Name H801SCUB H801SCUF H801SCUN Upstream interface board
Issue 01 (2011-10-30)
H801GICD
739
21 Ethernet OAM
Board Type
Board Name H801GICE H801GICF H801GICG H801GICK H801GSCA H801X1CA H801X2CA H801X2CS
Universal interface board SPU board Ethernet service board
H801CITD H801SPUA H801ETHA H801ETHB
GPON board
H801GPBC H802GPBD H805GPBD
P2P interface board
H801OPFA H802OPGD
VDSL2 service board
H805VDSA H805VDSF H805VDTF H805VDRD H805VDMF H802VDNF H802VDJM H80BVDPE H80BVDPM H85BVDMD
SHDSL service board
H803SHDA H802SHLB H80ASHLM
Issue 01 (2011-10-30)
740
21 Ethernet OAM
NOTE
The SCUL control board supports capture of ETH CFM packets. However, the SCUL control board does not support an ETH port and therefore the SCUL control board does not fully support ETH OAM CFM. If the MA5600T/MA5603T provides the board supporting ETH OAM CFM, the SCUL control board can forward ETH CFM packets to the Ethernet service board for processing.
Table 21-5 lists the relationship between the number of MEPs (including remote MEPs and local MEPs) that can be created on the MA5600T/MA5603T and the interval of sending continuity check messages (CCMs). Table 21-5 Relationship between the number of MEPs and the interval of sending CCMs Interval of Sending CCMs 10 minutes 1 minute 10s 1s 100 ms (supported only by SPUA) 10 ms (supported only by SPUA) 3.3 ms (supported only by SPUA) Number of MEPs 4096 512 128 16 64 64 64
NOTE
If maintenance associations (MAs) of the MA5600T/MA5603T send CCMs at different intervals, the interval of the MA supporting the fewest MEPs prevails.
21.3.4 Principle
Ethernet CFM OAM supports connectivity check (CC), loopback (LB), and linktrace (LT). CC is used by network planning engineers and data configuration engineers; LB and LT are used by maintenance engineers. The specific usage is as follows: 1. In network planning, network planning engineers demarcate maintenance domain (MD) and maintenance association (MA) scopes and specify maintenance end points (MEPs) and maintenance intermediate points (MIPs) in the MAs according to the network topology and Ethernet links to be monitored. Data configuration engineers issue Ethernet CFM OAM configurations to devices in the MDs and MAs according to the network plan and enable CC of MEPs and MIPs in the MAs. Maintenance engineers monitor connectivity of Ethernet links among CC-enabled MEPs and MIPs in the MAs using the alarming function. If a CCM-related alarm is generated, maintenance engineers locate the Ethernet link interruption using LB and LT.
2.
3.
Issue 01 (2011-10-30)
741
21 Ethernet OAM
Principle of CC
To ensure the connectivity between two MA5600T/MA5603Ts, add the two MA5600T/ MA5603Ts to the same MA (for example, MA 0) of the same MD (for example, MD 0), and configure MA5600T/MA5603T-1 and MA5600T/MA5603T-2 as two mutual MEPs. The ETH access port of MA5600T/MA5603T-1 is connected to the GIU upstream port of MA5600T/ MA5603T. l MA5600T/MA5603T-1: Assume that the ETH access port is configured as MEP 1, as shown in Figure 21-1. MEP 1 needs to send packets to the hardware and logic. Therefore, MEP 1 is configured as the UP MEP. MA5600T/MA5603T-2: Assume that the GIU upstream port is configured as MEP 2, as shown in Figure 21-1. MEP 2 needs to send packets to the convergence switch. Therefore, MEP 2 is configured as the DOWN MEP.
Figure 21-1 shows the working principle of CC. Figure 21-1 Working principle of CC
Link 1 Link 2 Link 3 Link 4
MEP1 MIP1 MIP2 MIP3 MIP4 MIP5 MIP6 MEP2 Switch Switch Switch MA5600T/ MA5600T/ MA5603T-1 MA5603T-1 CCM Port MIP MEP
CC is monitored through the CCMs multicasted at intervals to the domain. The working principle is as follows: 1. 2. 3. Each MEP (for example, MEP 1) actively multicasts the hello messages (CCMs) at intervals to the domain. A CCM contains the configuration information of the MEP. Every MIP and MEP (for example, MEP 2) can receive CCMs but need not send the response messages. The MIP and MEP 2 that receive the CCMs set up an MEP database in the format of [MEP DA, Port]. When MEP 2 receives the CCM from MEP 1, MEP 2 checks the information contained in the CCMs and saves the CCMs to learn about different MAs. The source addresses for a group of expected MEPs (MEP 1 in this example) must be configured on MEP 2. If MEP 2 fails to receive any CCMs or the information carried in the received CCMs is not the information that MEP 2 expected within a certain period of time, the network between MA5600T/MA5603T-1 and MA5600T/MA5603T-2 is considered failed. MEP2 checks the information by comparing the received CCM with the source address of the expected MEP (MEP 1). MA5600T/MA5603T-2 reports a CCM loss alarm.
NOTE
4.
5.
CC can determine whether a fault occurs on the network and notify the maintenance engineers by sending CCM-related alarms, but cannot locate the section of the link where the fault occurs. After a CCM-related alarm is generated, maintenance engineers can locate the Ethernet link interruption using LB and LT.
Issue 01 (2011-10-30)
742
21 Ethernet OAM
Table 21-6 describes CCM-related alarms that may be generated if faults occur on a network. Table 21-6 ETH OAM CCM alarms Alarm Loss of Ethernet connectivity check message Trigger Condition In normal conditions each MEP sends continuity check messages (CCMs) periodically, and all the other MEPs in the same MA can receive the CCMs. If the CCM from a certain MEP is not received within a period equal to 3.5 times the sending interval, the device transits to the waiting-for-alarm state; if the CCM is not received after another 2.5s, the system generates this alarm. In normal conditions each MEP sends CCMs periodically, and all MEPs and MIPs in the MD can receive the CCMs. If an MEP receives an invalid Ethernet CCM, the system generates this alarm. In normal conditions each MEP sends CCMs periodically, and all MEPs and MIPs in the MD can receive the CCMs. After an MEP receives the CCM sent from the peer MEP, the system generates this alarm if the MEP receives the Ethernet CCM from different MAs or MDs, or from a lower-level MD. In normal conditions each MEP sends CCMs periodically, and all MEPs and MIPs in the MD can receive the CCMs. When an MEP cannot receive the CCM packet sent from a remote MEP (RMEP), the MEP's RDI bit in the broadcast CCM is set to 1. If the CCM with RDI bit 1 is received, the system generates this alarm.
Reception of invalid Ethernet connectivity check message Reception of Ethernet cross connect connectivity check message Reception of Ethernet connectivity check message with the RDI bit set
Principle of LB
A loopback detection message (LBM or LBR) is sent from an MEP to a specified MIP or MEP to help the MEP locate the fault in the MA. Figure 21-2 shows the working principle of LB. Figure 21-2 Working principle of LB
Link 1 MEP1 MIP1 MA5600T/ MA5603T-1 Switch
Link 2
Link 3
Link 4
MIP2
MIP3 Switch
MIP4
MIP5 Switch
MIP6
MEP2 MA5600T/ MA5603T-2
LBM LBR Port MIP MEP
Issue 01 (2011-10-30)
743
21 Ethernet OAM
The MIP or MEP ahead of the fault location can respond to the LB message (that is, the MIP or MEP sends the LBR packet), but the MIP or MEP behind the fault location cannot respond to the loopback message (that is, the MIP or MEP cannot send the LBR). In this way, the fault is located. The working principle of LB is as follows:
NOTE
The MEP must know the MAC address of the MIP or MEP to which the LBM is transmitted. Before an LB, l Configure the CCM so that it can record the information about the RMEP. l Obtain the MAC address through the LTM. The LTM can acquire the MAC address of the MIP or RMEP.
1. 2.
As shown in Figure 21-2, MEP 1 sends the LBM to MIP 1. If link 1 is normal, MEP 1 receives the LBR responded from MIP 1.
NOTE
The MIP only sends the LBM to the MEP but does not forward the LBM to the next hop MIP or MEP.
3. 4. 5. 6. 7.
MEP 1 sends the LBM to MIP 2 (the next hop of MIP 1). MEP 1 receives the LBR responded from MIP 2. MEP 1 continues to send the LBM to MIP 3 (the next hop of MIP 2). MEP 1 cannot receive the LBR responded from MIP 3 because link 2 fails. MA5600T/MA5603T-1 can determine that the link between MIP 2 and MIP 3 (link 2) fails.
NOTE
LB is a method of diagnosing faults for any path only if the MAC addresses of all the MIPs (or MEPs) between MA5600T/MA5603T-1 and MA5600T/MA5603T-2 are known.
Principles of LT
The LT message (LTM and LTR) is used for checking the MIP path between two MEPs. All the MIPs on a link send the LT response message (LTR) to the MEP that initiates an LT message (LTM), and forward the LTM until it reaches the destination MIP or MEP. Figure 21-3 shows the working principle of LT.
Issue 01 (2011-10-30)
744
21 Ethernet OAM
Figure 21-3 Working principle of LT

Link 1 MEP1 MIP1 MA5600T/ MA5603T-1 Switch MIP2 MIP3 Switch MIP4 MIP5 Switch MIP6 MEP2 MA5600T/ MA5603T-2 Link 2 Link 3 Link 4
LTM LTR Port MIP MEP
If the destination is an MEP, each MIP in an MA responds to the source MEP. The source MEP learns about the MAC addresses and locations of all the MIPs, and the link section where the fault occurs through the LTR. The working principle of LT is as follows: 1. 2. 3. 4. When all links are normal, MEP 1 sends an LTM to MEP 2. MIPs 1, 2, 3, 4, 5, and 6 sends an LTR to MEP 1 after receiving the LTM, and reduces the TTL by 1 and forwards the LTM to the next hop. After MEP 2 receives the LTM, it does not forward the LTM but sends an LTR to MEP directly. As shown in Figure 21-3, after MEP 1 sends an LTM to MEP 2 when link 2 between MIP 2 and MIP 3 fails, MEP 1 can receive an LTR from only MIP 1 and MIP 2 but not from MIP 3. Thus, the location where the fault occurs can be determined.
21.4 Ethernet EFM OAM

Ethernet EFM OAM provides a mechanism for monitoring links. It can serve as a complement to the higher layer applications. This topic provides an introduction to this feature, and describes the availability and working principle of this feature.
21.4.1 Introduction
Definition of EFM
OAM provides the mechanism for network administrators to monitor the network health condition and to quickly locate the faulty links and determine the fault condition. Ethernet in the First Mile (EFM) OAM is defined in IEEE 802.3ah Clause 57 by the IEEE EFM Workgroup. It is an important part of Ethernet OAM. Ethernet EFM OAM provides a mechanism
21 Ethernet OAM
for monitoring links, such as remote defect indication (RDI) and remote loopback control. It is a mechanism at the data link layer, and is a complement to the higher layer applications.
Definition of OAMPDU
In addition to the RDI and remote loopback functions, Ethernet EFM OAM also provides an OAM discovery mechanism, namely, an extended mechanism for the higher layer applications. The above-mentioned functions are implemented by the exchange of the following types of OAM protocol data units (OAMPDUs) between two neighboring entities on an Ethernet link. l Information OAMPDU: It is used to transmit the OAM status information to the remote end, including the OAM capability, multiplexer status, and parser status of the local end, and the matching between the OAM capability of the local end and that of the remote end. Here, the OAM capability refers to: Whether unidirectional transmission is supported. This capability directly determines whether RDI is supported. Whether the response to the variable query is supported. That is, whether the query about the local end information is supported. Whether remote loopback is supported. That is, whether the local end can be set to the loopback state by the remote end. Whether the link parsing event is supported. That is, whether the link event transmitted from the remote end can be processed. Information PDU also includes the Organizationally Unique Identifier (OUI) field and the Vendor Specific Information field, through which the vendor information of the remote end can be learned. l Event Notification OAMPDU: It is used to notify the remote end of specific events, such as how many errored frames are received in a certain period and what is the threshold of errored frames. Variable Request OAMPDU: It is used to query one or more MIB variables from the remote end, such as the number of correctly received or transmitted frames. Variable Response OAMPDU: It is used to return one or more MIB variables to the remote end after the Variable Request OAMPDU is received. Loopback Control OAMPDU: It is used to control the loopback state of the remote end. When the remote end is in the loopback state, the data frames received by the remote end, except OAMPDUs, are looped back to the local end.
l l l
Purpose
The MA5600T/MA5603T supports EFM OAM to obtain the alarm information (such as RDI) about the Ethernet terminal, and supports the exchange of OAMPDUs to obtain the information about the terminal device vendor.
Limitations
l When the EFM of the local DTE and the EFM of the remote DTE are in the passive mode, the EFM function cannot be enabled. To enable the EFM function, the EFM of one end must be in the active mode. EFM OAM must be supported by the remote DTE. If it is not supported by the remote DTE, the line between the local DTE and the remote DTE cannot communicate normally.
Issue 01 (2011-10-30)
21 Ethernet OAM
l l
The remote loopback function is dependent on the remote DTE. If it is not supported by the remote DTE, the remote loopback function also fails. When the remote loopback function is enabled, the line between the local DTE and the remote DTE is in the loopback state. In this case, the non-OAMPDUs transmitted by the remote DTE are directly looped back, and all the packets transmitted by the local DTE are discarded. The system can receive, transmit, and process Information OAMPDUs for performing the OAM discovery and obtaining the information about the terminal device vendor. The system can parse the received Event Notification OAMPDUs. The system can transmit and respond to the Loopback Control OAMPDUs. That is, it can initiate and respond to a remote loopback. The system cannot transmit or respond to the Variable Request OAMPDUs. That is, it does not support the query about the remote MIB variables.
l l l l
21.4.2 Availability
l l Hardware Support The OPFA, OPGD, VDSL, and SHDSL boards support this feature. License Support The Ethernet EFM OAM feature is an optional feature of the MA5600T/MA5603T, and the corresponding service is controlled by the license.
21.4.3 Principle
The main functions of the Ethernet EFM OAM feature are as follows: l Remote defect indication (RDI): If an Ethernet link between an ONU and the OLT supports unidirectional transmission (that is, when one direction is faulty, data can still be transmitted in the other direction), the faulty receiving end can transmit a special OAMPDU to notify the remote end of the local fault. Remote loopback: The local end controls the remote end to enter the loopback state by transmitting a special OAMPDU. After the remote end enters the loopback state, the packets except OAMPDUs transmitted from the local end to the remote end are directly looped back.
Remote Defect Indication

Figure 21-4 shows an example network of the Ethernet EFM OAM feature. Figure 21-4 Example network of the Ethernet EFM OAM feature
Ethernet OAM packet Ethernet link ONU OLT
Issue 01 (2011-10-30)
747

NOTE
21 Ethernet OAM
The EFM OAM packets are exchanged only between two neighboring entities on a link and are not forwarded out of the link.
The principle of the RDI function of Ethernet EFM OAM is as follows: 1. 2. Ethernet EFM OAM is enabled on both the local OLT and the remote ONU. When a critical event occurs on the remote ONU, such as a link fault or an undefined critical event, the remote ONU transmits an Event Notification OAMPDU to inform the local OLT of the fault. After receiving and parsing the packet, the local OLT reports an alarm to the host.
3.
Remote Loopback
NOTE
l As defined in IEEE 802.3ah, the EFM loopback refers to the loopback at the data link layer controlled by the remote end. This function is mainly used for locating the specific area of a fault and for testing the link quality. The quality tests include the tests on the throughput, BER, delay, and jitter of packets. l The prerequisite for enabling the remote loopback is that it is supported by the remote DTE. The remote loopback can be configured only when it is supported by the remote DTE.
CAUTION
l When the remote loopback is enabled, the local DTE and the remote DTE stop transmitting frames. The local DTE will not receive or transmit any packet, and at the same time transmits an OAMPDU to the remote DTE, instructing the remote DTE to enable the remote loopback. l When the remote loopback is enabled, the services of all the users connected to the DTE involved are interrupted. Therefore, exercise caution when using this function. Figure 21-5 shows the principle of the remote loopback function of Ethernet EFM OAM.
Issue 01 (2011-10-30)
748
21 Ethernet OAM
Figure 21-5 Principles of the remote loopback function of Ethernet EFM OAM
OLT ONU Ethernet OAMPDUs Ethernet link Remote DTE Local DTE 1 Local DTE receives OAM loopback configuration and stops transmitting frames. The multiplexer state machine and parser state machine are in discard state. 2 2 Local DTE transmits remote loopback control OAMPDU to remote DTE.
3 After receiving remote loopback control OAMPDU, remote DTE sets its multiplexer state machine to discard state and parser state machine to loopback state.
4 Remote DTE responds with Information OAMPDU to local DTE, informing local DTE that multiplexer state machine on remote DTE is in discard state and parser state machine is in loopback state.
5 After receiving Information OAMPDU, local DTE sets its multiplexer state machine to forward state. 6 Local DTE starts transmitting loopback frames to remote DTE.
7 Local DTE compares transmitted frames with looped back frames, thus determining the health condition of the link.
The principle of the remote loopback function of Ethernet EFM OAM is as follows: 1. The local DTE receives the OAM loopback configuration information and stops transmitting frames. The multiplexer state machine and the parser state machine are in the discard state. The local DTE transmits the remote loopback control OAMPDU to the remote DTE. After receiving the remote loopback control OAMPDU, the remote DTE sets its multiplexer state machine to the discard state and the parser state machine to the loopback state. The remote DTE responds with the Information OAMPDU to the local DTE, informing the local DTE that the multiplexer state machine on the remote DTE is in the discard state and the parser state machine is in the loopback state. After receiving the Information OAMPDU, the local DTE sets its multiplexer state machine to the forward state. The local DTE starts transmitting loopback frames to the remote DTE.
NOTE
2. 3. 4.
5. 6.
When the link and the remote DTE are in the normal state, the remote DTE directly loops back the loopback frames to the local DTE.
7.
The local DTE analyzes the MAC address frames transmitted by the local DTE and the MAC address frames looped back by the remote DTE. By comparing the transmitted frames with the looped back frames, the local DTE can determine whether quality problems such as delay and bit error occur, and thus knowing the health condition of the link.
Issue 01 (2011-10-30)
749
21 Ethernet OAM

Glossary
Table 21-7 Glossary of the terms related to the Ethernet OAM feature Term CFM Description Connectivity Fault Management (CFM) is an end-to-end Ethernet connectivity management. It is a main protocol for implementing Ethernet OAM. CFM can be understood as a subset of OAM. A maintenance entity (ME) is a maintainable device on a network. Basically, an ME is a bridge on the network, that is, the device that can forward packets according to the "VLAN+MAC". A maintenance domain (MD) is a combination of bridges and maintenance levels. An MD contains several maintenance associations (MAs). Each MA is associated to a service instance (SI) which is identified by VLAN in the MD. That is, an MA is a combination of an MD and a VLAN. Ethernet CFM OAM performs CD for each MA. An MA contains several maintenance points (MPs). An MP is the port on a bridge device. That is, an MP is a combination of a bridge port, a VLAN, and a maintenance level. An MP can be a maintenance entity points (MEP) or a maintenance intermediate points (MIP). An MEP can be configured for each MA, and must be the edge node in the MA. An MEP is a port of a device. RMEP The MEP on any device that runs Ethernet CFM OAM is called the local MEP. The MEPs on the other devices in the same MA are the remote maintenance association end points (RMEPs) to the local MEP. An UP MEP indicates that the MEP transmits packets to the bridge trunk direction. A DOWN MEP indicates that the MEP transmits packets to the physical medium direction. When a device port is defined as an MEP, it must be defined as the UP MEP or the DOWN MEP. In addition, it can be defined as only either the UP MEP or the DOWN MEP. That is, when a device port is defined as an MEP, it can transmit packets to only one direction. For example, after the GIU upstream port on the MA5600T/MA5603T is defined as an MEP, it is a DOWN MEP if it can transmit packets to only the upstream direction (convergence layer) according to the definition; it is an UP MEP if it can transmit packets to only the downstream direction (to hardware and logic) according to the definition.
ME
MD MA
MP
UP MEP and DOWN MEP
Issue 01 (2011-10-30)
750
21 Ethernet OAM
Term EFM
Description Ethernet in the First Mile (EFM) defines the Ethernet physical layer specifications in the user access part and the Ethernet OAM in the access part. EFM is mainly used for the link detection of the last mile. It is a link-level OAM and can be regarded as a subset of OAM. The Ethernet OAM discovery function is used for discovering the remote DTE, including the OAM configuration, OAM mode, OAMPDU information, and OUI information of the remote DTE. Remote defect indication (RDI) is a function for diagnosing the remote DTE. When the remote DTE is faulty or fails and causes traffic interruption, a notification is sent to the local device through the flag field of the OAMPDU. Remote loopback is to set the remote DTE to enter the loopback state through commands. The EFM remote loopback function is mainly used for locating faults and testing the link performance. In the remote loopback mode, the statistical packets of the local device and the remote DTE can be queried and compared for the abovementioned purpose. It is a state machine defined by IEEE 802.3ah for controlling the packet transmitting. It is a state machine defined by IEEE 802.3ah for controlling the packet receiving.
OAM discovery
RDI
Remote loopback
Multiplexer state machine Parser state machine

Table 21-8 Acronyms and abbreviations of the Ethernet OAM feature Acronym/Abbreviation OAM STP CFM MD MA MEP RMEP MIP CC LB Full Spelling Operations Administration and Maintenance Spanning Tree Protocol Connectivity Fault Management Maintenance Domain Maintenance Association Maintenance End Point Remote Maintenance association End Point Maintenance Intermediate Point Continuity Check Loopback
Issue 01 (2011-10-30)
751
21 Ethernet OAM
Acronym/Abbreviation LT TLV EFM OAMPDU OUI RDI DTE
Full Spelling Linktrace Type, Length, and Value Ethernet in the First Mile OAM Protocol Data Unit Organizationally Unique Identifier Remote Defect Indication Digital Terminal Equipment
Issue 01 (2011-10-30)
752
22 Redundancy Backup of the Control Boards
22
Redundancy Backup of the Control Boards
About This Chapter

When two control boards switch over in a redundancy backup system, the service of the system will not be interrupted even if the control board fails or is upgraded. This topic provides introduction to this feature and describes the principle and reference documents of this feature. 22.1 Introduction 22.2 Specifications 22.3 Availability 22.4 Principle
Issue 01 (2011-10-30)
753
22.1 Introduction
Definition
Redundancy backup of the control boards means that two control boards are configured in the system, one acting as the active control board and the other as the standby control board.
Purpose
When two control boards switch over in a redundancy backup system, the service of the system will not be interrupted if the control board fails or is upgraded.
22.2 Specifications
The active/standby switchover of the system includes the following functions: l l l Scheduled switchover Automatic switchover in case of a control board failure Query about the synchronization status of the active and standby control boards
The SCUN control board also supports the load balancing mode. In the load balancing mode, the valid bandwidth of each service slot is 20 Gbit/s.
22.3 Availability
Hardware Support
The SCUB, SCUL, and SCUN board support redundancy backup.
License Support
The redundancy backup of the control boards is the basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
22.4 Principle
The in-service switchover process is as follows: 1. 2. Save the database file. That is, save the configured system data to the database of the flash memory of the control board. Back up the database file. (1) Start the FTP/TFTP/SFTP file server. (2) Back up the current database of the system to the FTP/TFTP/SFTP server. (3) Use an external database upgrade tool to upgrade the current database to the database of a new version.
3. 4.
Load the new version of the database to the active and standby control boards, and make sure that the databases of the active and standby control boards are the same. Load the software package, including programs, multi-lingual file, and board software for the new release to the active and standby control boards.
NOTE
There is no strict sequence requirement on the program and database loading.
5. 6. 7.
Reset the standby control board. After it is reset, initialize it using the new programs and database. After the standby control board recovers, check the synchronization state of the active and standby control boards. If the active and standby boards are fully synchronized, switch over between the active and standby control boards. After the switchover, the previous standby control board becomes the active control board, and smoothing is performed on the standby control board. In this way, the service provisioning remains in the normal state. The control boards of the original system get reset. After that, start up the programs and the new version of the database and recover the system according to the initialization process of the standby control board of the same version. After the new version starts up successfully, the data of the active and standby control boards is synchronized according to the active/standby synchronization mechanism of the same version. After data synchronization, the system gets upgraded successfully.
8.
9.
10. The operations are recorded in the system logs, and the corresponding alarms are reported, including the active/standby switchover alarm and the standby board recovery alarm.
NOTE
After the IO board package file is loaded, certain service boards will be restarted and services carried on the service boards will be interrupted for a period of time.
Issue 01 (2011-10-30)
755
23 Clock Feature
23
About This Chapter
This topic describes the feature of the clock system.
Clock Feature
23.1 NTP The Network Time Protocol (NTP) is used to synchronize the time between the distributed time server and the client. 23.2 Clock and Time System This topic describes the definition and principle of the clock and time system of the MA5600T/ MA5603T, and describes the specific applications of clock and time synchronization.
Issue 01 (2011-10-30)
756
23 Clock Feature
23.1 NTP
The Network Time Protocol (NTP) is used to synchronize the time between the distributed time server and the client.
23.1.1 Introduction
Definition
The Network Time Protocol (NTP) is an application layer protocol in the TCP/IP protocol suite. NTP is used to synchronize the time between the distributed time server and the client. The implementation of NTP is based on IP and UDP.NTP involves the Time Protocol and the ICMP Timestamp Message, with special design on accuracy and robustness.
Purpose
NTP defines the accurate time in an entire network. Because the network topology is complicated, the clock synchronization among all the devices in the entire network becomes more critical. The objective of NTP is to synchronize the clocks of all the devices in a network which have clocks. This helps to keep time consistency among all the devices in the network. Therefore, the equipment can offer various applications based on the clock synchronization. The MA5600T/MA5603T supports the NTP feature to guarantee that the clocks of all the devices in a network are consistent.
The MA5600T/MA5603T supports the following NTP specifications: l l l l l l l l l l l l NTP Version3 NTP client/server mode NTP LAN broadcast mode NTP multicast mode NTP peer mode Clock filtering and selection Local clock calibration Clock source priority selection Support of the reference clock NTP security features Up to 128 peers in a static configuration Up to 100 peers in a dynamic configuration

The following provides the reference documents of NTP:
23 Clock Feature
RFC1305.txt, "Network Time Protocol (Version 3) Specification, Implementation and Analysis"
23.1.4 Availability
License Support
The NTP feature is the basic feature of the MA5600T/MA5603T. Therefore, no license is required for accessing the corresponding service.
Version Support
Hardware Support
No additional hardware is required for supporting the NTP feature.
23.1.5 Principle
As shown in Figure 23-1, the MA5600T/MA5603T serves as the NTP client and the router serves as the NTP server. The MA5600T/MA5603T uses the time of the router as the reference and synchronizes its time with the router through NTP. Figure 23-1 Operating principle of NTP
MA5600T/MA5603T NTP packet 10:00:00am Step 1: NTP packet 10:00:00am 11:00:01am Router
Step 2:
NTP packet 10:00:00am 11:00:01am 11:00:02am Step 3:
NTP packet received at 10:00:03 Step 4:
Issue 01 (2011-10-30)
758
23 Clock Feature
1.
The MA5600T/MA5603T sends an NTP packet to the router. This packet contains the timestamp when it leaves the MA5600T/MA5603T. Assume that the timestamp is 10:00:00 am (T1). When the NTP packet arrives at the router, the router adds its timestamp to the packet. Assume that the timestamp is 11:00:01 am (T2). When the NTP packet leaves the router, the router adds another timestamp to the packet. Assume that the timestamp is 11:00:02 am (T3). When the MA5600T/MA5603T receives the response packet, it adds a new timestamp to the packet. Assume that the timestamp is 10:00:03 am (T4).
2. 3. 4.
Now, the MA5600T/MA5603T has sufficient information to calculate two important parameters: l l The delay for a round trip of the NTP packet = (T4-T1) - (T3-T2). Offset between the MA5600T/MA5603T and the router = ((T2-T1)-(T4-T3))/2
In this way, the MA5600T/MA5603T can set its clock according to the information and thus keeps its clock synchronized with that of the router.
23.2 Clock and Time System

This topic describes the definition and principle of the clock and time system of the MA5600T/ MA5603T, and describes the specific applications of clock and time synchronization.
23.2.1 Introduction
Definition
IP-nization is the trend of future network and service development, so is the trend of the bearer network. Difficulties, however, currently exist in the transition from the SDH-based traditional network to the IP-based Ethernet bearer network. One key technology involved is how to bear traditional TDM service on the new network. Traditional TDM service has two major applications: voice service and clock synchronization service. In a traditional communications network architecture, the TDM service of the fixed network is mainly voice service. Cumulative inconsistency between the clocks at both ends of the bearer network over a long time causes bit slip. The ITU-T Recommendation G.823 defines the requirements on and the test standards of the TDM service of the fixed network. The definition is called the G.823 traffic interface standard. Apart from the bearer network, a traditional communications network usually contains an independent clock-issuing network, which adopts PDH/SDH for issuing clock signals. As specified by the ITU-T, the clock must meet the G.823 TIMING interface requirements. In a communications network, the wireless application has the most rigorous requirements on the clock frequency. The frequencies of different BTSs must be synchronized within a specified precision. Otherwise, re-synchronization occurs during the BTS switching. Current wireless technologies are in different systems. Different systems have different requirements on the clock bearing. European systems, of which the GSM/WCDMA is a representative, adopt the asynchronous base station technologies. In this case, only frequency synchronization is required, at a precision of 0.05 ppm (or 50 ppb). The clock needs to be provided by the bearer network. The traditional solution is to provide the clock through PDH/SDH. After the IP-nization, the
23 Clock Feature
clock needs to be provided by the IP network. The synchronous BTS technologies, of which the CDMA/CDMA2000 is a representative, require phase synchronization of the clock (also called time synchronization). Table 23-2 lists the detailed requirements on clocks.
NOTE
Clock synchronization is frequency synchronization. Time synchronization is phase synchronization, which requires both phase synchronization and frequency synchronization at the same time.
Table 23-2 Requirements of different standards on the clock and time Wireless System GSM WCDMA TD-SCDMA CDMA2000 WiMax FDD WiMax TDD LTE Frequency Precision 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm Phase Synchronization Precision 3 s 3 s 1 s Time synchronization is preferred.
Currently, the following types of clock technologies are available: l l l BITS clock TDM service emulation clock Synchronous Ethernet clock
Purpose
The purpose is to ensure the clock synchronization between communications devices and communications networks.
Scenarios of clock and time synchronization are as follows: l l l In the scenario involving only broadband Internet access service, clock synchronization is not required. The voice service does not require clock synchronization and voice quality will not be affected. Clock synchronization is required for high-speed fax service (similar to high-speed modem service) that needs to stay always online; if always online is not required, clock synchronization is not required. TDM private line services require clock synchronization. The services include terminating native TDM for upstream transmission through E1; terminating SAToP for upstream
Issue 01 (2011-10-30)
23 Clock Feature
transmission through E1; terminating native TDM for upstream transmission through STM-1; terminating SAToP for upstream transmission through STM-1. l In the mobile bearing scenario, the CKMC stratum-3 clock daughter board needs to be configured if the base station obtains clock signals from the MA5600T/MA5603T.
The MA5600T/MA5603T supports the following clock processing functions: l l l l l l l l l l l l l Supports G.813 synchronization. Supports G.8262 clock synchronization. Supports active/standby configuration of the clock module (CKMC). Supports BITS clock ports (configurable at 2 MHz and 2 Mbit/s). E1 and STM-1 service ports support the stratum-3 clock function. Supports synchronous Ethernet, including GE optical ports. Supports SAToP line clock recovery and supports the ACR mode; does not support the differential mode. Supports the SAToP line recovered clock serving as the transmit clock source of other lines of the same board, but currently not serving as the system clock source. xPON ports support synchronous issuing of clock signals. G.SHDSL, ADSL2+, and VDSL2 ports support synchronous issuing of NTR clock signals. Supports two 1 PPS+TOD external time input ports. Supports quality level management for SSM clocks. Supports exporting of STM-1/E1/synchronous Ethernet line clock signals.

The following lists the reference standards and protocols of this feature: l ITU-T G.813 Timing characteristics of SDH equipment slave clocks (SEC) ITU-T G.813 defines the requirements on synchronization by SDH devices. The native TDM, CESoP, and ATM services provided by the MA5600T/MA5603T are carried through the STM-1 port. Therefore, the ITU-T G.813 requirements on the clock feature must be met. ITU-T G.813 specifications include the following items. To meet the ITU-T G.813 specifications, the MA5600T/MA5603T must be configured with the CKMC stratum-3 clock daughter board. Items defined by the G.813 Recommendations: Frequency accuracy Pull-in and pull-out ranges Wander generation Jitter output Input wander tolerance Input jitter tolerance Noise transfer Short-term phase transient response Long-term phase transient response (holdover) Phase response to input signal interruptions Phase discontinuity
23 Clock Feature
ITU-T G.823 (the control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy) The ITU-T G.823 describes the jitter and wander of the PDH interface in the 2048 kbit/s synchronous system. Here, the E1 port is mainly referred to, which meets the G.824 requirements for the 1544 kbit/s system. G.823 defines the requirements on the traffic interface and the synchronization interface. The traffic interface performance is the basic requirement for service transmission. To transmit synchronous clock signals, the E1 port must meet the requirements of the synchronization interface. The synchronization interface has stricter requirements on jitter and wander than the traffic interface does. The G.823 defines the following items for the traffic interface and the synchronization interface: Jitter output Output wander Input jitter and wander tolerance
ITU-T G.736, Characteristics of a synchronous digital multiplex equipment operating at 2048 kbit/s The ITU-T G.736 defines the jitter transfer characteristics of the E1 port. ITU-T G.825, The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH) The ITU-T G.825 defines the jitter and wander characteristics of SDH devices. The ITU-T G.825 defines the following items for the STM port: Jitter output Output wander Input wander tolerance Input jitter tolerance Jitter and wander generation Jitter and wander transfer
ITU-T G.8261, Timing and Synchronization Aspects in Packet Networks The ITU-T G.8261 defines the wander budget of CES and synchronous Ethernet for packet networks. The ITU-T G.8261 requirements are similar to the requirements of the ITU-T G. 823 on the TDM network. The CESoP service and synchronous Ethernet clock feature of the MA5600T/MA5603T need to meet the ITU-T G.8261 requirements.
ITU-T G.8262, Timing characteristics of synchronous Ethernet equipment slave clock (EEC) The ITU-T G.8262 defines the requirements on the synchronous Ethernet clock system, which are equal to the G.813 and G.812 requirements on the TDM network. To meet the ITU-T G.8262 specifications, the MA5600T/MA5603T must be configured with the CKMC stratum-3 clock daughter board.
ITU-T G.703, Physical/Electrical characteristics of hierarchical digital interfaces The E1 and BITS ports support the 75-ohm or 120-ohm impedance setting, and output physical signal template and rate that meet the ITU-T G.703 Recommendations.
ITU-T G.8264, Distribution of timing through packet networks The ITU-T Recommendation G.8264 defines the SSM protocol and message format for the synchronous Ethernet to ensure clock synchronization between Ethernet devices.
Issue 01 (2011-10-30)
762
23 Clock Feature
23.2.4 Availability
Version Support
Table 23-3 lists the MA5600T/MA5603T versions that support the clock and time synchronization feature. Table 23-3 Versions supporting the clock and time synchronization feature Product MA5600T/MA5603T Version V800R007 and later versions
23.2.5 Enhancement
Version V800R008C01 Enhancement l Supports directly exporting line clock signals, which are used as the clock source of other devices. l Supports quality level management for SSM clocks.
23.2.6 Principle of the Clock and Time System

The clock system of the MA5600T/MA5603T consists of three parts: system clock/time synchronization source, phase-locked loop circuits, and clock/time output, as shown in Figure 23-2.
Issue 01 (2011-10-30)
763
23 Clock Feature
Figure 23-2 Solution for the clock and time synchronization system
System clock output TOPA card GSCA/X2CS /GICK SPUA/ETHB/ OPFA/OPGD xPON card TOPA card GSCA/X2CS /GICK SPUA Line clock source Selector CITD 1PPS+TOD BITS B port Clock output BITS_IN1 BITS_IN0 2 MHz,2 Mb/s 1PPS+TOD GICK 1588 packet
Selector
xDSL card EDTB card 1588 packet output xPON card GICK
CKMC PLL System phaselocked loop
SCU card (active)
NOTE
The stratum-3 clock daughter boards of the MA5600T/MA5603T are integrated as the CKMC. The CKMC daughter board supports the clock performance required by G.813 and G.8262, and the active/standby configuration. As a BITS interface board, the CITD board provides two BITS inputs and one BITS output. When the system is not configured with a stratum-3 clock daughter board, the hardware phase-locked loop of the control board can be used to provide the system clock with a precision of 25 ppm.
23.2.6.1 Clock/Time Synchronization Source

The MA5600T/MA5603T supports clock sources of four types: the BITS clock source, the line clock source, and the internal clock source.
BITS Clock and Time Synchronization Source

The MA5600T/MA5603T can lock the BITS input clock source, and supports the 2.048 Mbit/ s bit stream (HDB3) or the 2.048 MHz clock signal as the input mode. The MA5600T/MA5603T can synchronize with the BITS 1 PPS+TOD signals. BITS interface boards include H801CITD, which provides two 120-ohm BITS inputs. If different impedances are required, external impedance conversion adapter can be used for converting between the 75-ohm and 120-ohm impedances.
Line Clock Source

The MA5600T/MA5603T can lock the line recovered clock source. Ports supporting line clock recovery include STM-1 port, E1 port, and synchronous Ethernet port. These ports have the synchronous relationship at the physical layer. The clock recovered from the bit streams of lines can serve as the system clock source.
23 Clock Feature
Boards supporting the STM-1 line clock recovery on the MA5600T/MA5603T include H801TOPA (configured with the H801CSSA daughter board) and H801TOPA (configured with the H801O2CE daughter board). Boards supporting the E1 line clock recovery on the MA5600T/MA5603T include H801TOPA (configured with the H801NH1A daughter board) and H801TOPA (configured with the H801EH1A daughter board). Boards supporting the Ethernet line clock recovery on the MA5600T/MA5603T include H801X2CS, H801GSCA, H801GICK, and H801SPUA. The X2CS board supports 10GE synchronous Ethernet. The GSCA and GICK boards support GE synchronous Ethernet. The SPUA board supports 10GE and GE synchronous Ethernet. The H801ETHB does not support line clock recovery.
NOTE
The clock recovered from SAToP bit streams cannot serve as the system clock source but can serve as the port transmit clock of the same board.
Internal Clock Source

The MA5600T/MA5603T supports the internal clock source. When an external clock source is not configured or is faulty, the system can adopt the internal clock source in the free-run mode. Configuration of boards for internal clock source: l l Control board configured with the H801CKMC daughter board, providing a free-run precision within the tolerance of 4.6 ppm Control board not configured with the H801CKMC daughter board, providing a free-run precision within the tolerance of 25 ppm
23.2.6.2 Configuring the System Phase-Locked Loop

The stratum-3 clock unit of the system is an optional unit. When configured with the CKMC clock unit, the system provides high-quality clock output that meets the requirements of G.813 and G.8262. When the system is not configured with the stratum-3 clock unit, the system clock is provided by the hardware phase-locked loop. The quality of the clock thus provided meets the requirements of G.8261 or G.823. The quality of the clock provided for the SAToP service and native TDM service meets the requirements of G.8261 SAToP or G.823 traffic. The quality of the locked ideal line clock meets the requirements of G.8261 EEC or G.823 synchronization. In the case of the SAToP service and native TDM service, the clock quality is not directly related to the stratum-3 clock unit. The clock quality meets the requirements of G.8261 SAToP or G. 823 traffic.
23.2.6.3 Clock/Time Output

The MA5600T/MA5603T system outputs clock signals through the clock output interface or the synchronization service interface. The output clock signals serve as the reference clock of the device interconnected with the MA5600T/MA5603T. The synchronization service interface can select the system clock, line receive clock, board oscillator, or SAToP clock as the transmit clock. The interface is capable of outputting the system clock signals only when the system clock is selected as the transmit clock of the interface.
23 Clock Feature
Line Clock Output

The synchronization service ports of the MA5600T/MA5603T include the STM-1, PDH, synchronous Ethernet, xDSL, and xPON ports. The STM-1 port can select the system clock or the line receive clock of the port itself as the line transmit clock. Boards supporting the STM-1 port include H801TOPA (configured with the H801CSSA daughter board) and H801TOPA (configured with the H801O2CE daughter board). The PDH port is mainly used for the E1 mode (hardware compatible with the T1 mode). In the E1 mode, the system clock or the line clock can be selected as the transmit clock. Boards supporting PDH include EDTB and TOPA (configured with the EH1A daughter board). The transmit clock of the EDTB board is the system clock by default and cannot be the line clock. The transmit clock of the TOPA board (configured with the EH1A daughter board) can be the system clock, line clock, or SAToP clock. The E1 port of the TOPA board (configured with the NH1A daughter board) does not support the system clock as the transmit clock. The transmit clock of the synchronous Ethernet port is the system clock by default. The MA5600T/MA5603T supports the change of the transmit clock mode of the synchronous Ethernet port. The Ethernet port without the synchronization capability adopts the oscillator of the board as the transmit clock. The following boards support the synchronous Ethernet port: H801X2CS, H801GSCA, H801GICK, H801SPUA, H801OPFA, H802OPGD, and H801ETHB. The H801OPFA, H802OPGD, and H801ETHB boards do not support the recovery of the line receive clock, and support only the system clock output. The MA5600T/MA5603T functions as an OLT, and the line transmit clock of the GPON port is used as the system clock, the signals of which are transmitted to the ONT. The GPON boards of the OLT include the H801GPBC, H802GPBD, and H805GPBD.The EPON boards of the OLT include the H801EPBA and H801EPBD. The xDSL port with the synchronization capability is mainly used for the G.SHDSL emulation service. In the application of the emulation service, the G.SHDSL NTR clock should be set as the system clock. Board supporting the G.SHDSL service: H802SHLB.
Clock Output
The MA5600T/MA5603T provides one output clock, which is configurable. The system clock or the line clock can serve as the output clock. When the line clock is used, the system directly exports the signals of the line clock source and outputs the signals through the CITD board. When the system clock is used, the system phase-locks the clock signals and outputs the signals through the CITD board. The output interface board of the MA5600T/MA5603T is H801CITD.
Tributary Clock Output

The TOPA board (configured with the CSSA daughter board) is used for SAToP based on STM-1. The system clock, tributary receive clock, or SAToP recovered clock can be selected as the tributary E1 transmit clock of the TOPA board (configured with CSSA). l l System clock: The tributary E1 transmit clock synchronizes with the system clock signals issued by the control board. Tributary receive clock: The tributary E1 transmit clock synchronizes with the receive clock of the same port.
Issue 01 (2011-10-30)
23 Clock Feature
SAToP clock: The tributary E1 transmit clock synchronizes with a certain SAToP recovered clock. The recovery source of the SAToP clock can be flexibly selected as long as the SAToP is recovered within the board.
23.2.6.4 Working Principle of Clock Clock Working Mode

The MA5600T/MA5603T supports three clock modes: locked, holdover, and free-run. l Locked mode In this mode, the system clock source is synchronized with the input clock source. The phases of the system clock source and the input clock source are in a constant relationship. The MA5600T/MA5603T locks the BITS clock source, the line clock source. Locking an ideal clock source can meet the 50 ppb requirement for mobile bearing. l Holdover mode The MA5600T/MA5603T records the clock data of the locked mode. If the locked clock source is lost, the system builds a system clock by using the recorded clock data, and maintains the clock properties as consistent as possible with the clock properties of the locked mode. As such, the system enters the holdover mode. The precision of the holdover mode meets the G.813 or G.8262 requirements. l Free-run mode The system supports the free-run mode only when configured with the stratum-3 clock daughter board (CKMC). The system supports a maximum free-run duration of 24 hours. In the free-run mode, the MA5600T/MA5603T works based on the inherent frequency of its internal crystal oscillator.
Clock Source Selection and Switching

The MA5600T/MA5603T can be configured with up to 10 external clock sources. The system selects a clock source to serve as its reference clock according to a clock source selection algorithm. The MA5600T/MA5603T supports two clock source selection algorithms: based on clock source priority and based on SSM. If the algorithm is based on the clock source priority, the user needs to configure the external clock sources with different priorities. The system then automatically selects the clock source that has the highest priority and works in the normal state as the system reference clock. When the locked clock source of the system is faulty, the system automatically selects the clock source that has the second highest priority and works in the normal state as the reference clock. When the algorithm is based on SSM, the system extracts the clock quality level information from the clock source input signals. (In the case that the clock source does not support SSM information extraction, the user can manually configure the quality levels.) Then the system automatically selects the clock source that has the highest quality level and works in the normal state as the reference clock. If there are two external clock sources with the same highest quality level, the system selects the one that has the higher priority of the two clock sources. When the locked clock source of the system is faulty, the system automatically selects the clock source that has the second highest quality level and works in the normal state as the reference clock. In both clock source selection algorithms, if all the clock sources become unavailable, the system clock enters the holdover mode. In this mode, the clock unit is controlled according to the data recorded in the locked mode so that the clock unit generates clock properties similar to those of
23 Clock Feature
the clock in the locked mode. If a clock source recovers within the valid holdover period, the system returns to the locked mode. If the holdover period (a maximum of 24 hours) exceeds the data recording period of the locked mode, the system enters the free-run mode. Figure 23-3 shows the transition of the clock source modes. Figure 23-3 Transition of the clock source modes
System default
Local oscillator
C fa lo ils ck av so ai u la rc bl e e is
Lo ck in g
ol do ve r
t im es
ou t
Clock source recovers Locked All clock sources are lost
Holdover
Clock source is lost; switch to a lower priority clock source
23.2.7 Scenarios of Clock/Time Synchronization

23.2.7.1 Applications of Clock Output
By specific configuration, the MA5600T/MA5603T can select a system clock output or export the line clock. The output clock can serve as the clock source for other devices, as shown in Figure 23-4.
Issue 01 (2011-10-30)
768
23 Clock Feature
Figure 23-4 Clock Output

BITS B port Clock output BITS_IN1 BITS_IN0 2 MHz,2 Mb/s 1PPS+TOD GICK 1588 packet Selector TOPA card System clock is output by service board
CITD
Selector
CKMC PLL System phaselocked loop
GSCA/X2CS /GICK SPUA
SCU card (active)
Line clock source
When the system clock is selected as the output clock, the clock output through the CITD port is the system clock phase-locked by the MA5600T/MA5603T. The following clock sources can serve as the system clock: l l BITS clock source: CITD, including 2 Mb/s and 2 MHz signals. Line clock sources: STM-1 line clock: H801TOPA (configured with the H801CSSA daughter board) or H801TOPA (configured with the H801O2CE daughter board). E1 line clock: H801TOPA (configured with the H801NH1A daughter board) or H801TOPA (configured with the H801EH1A daughter board). l l Synchronous Ethernet line clock: H801X2CS, H801GSCA, H801GICK, or H801SPUA. Free-running internal clock source
When the line clock is selected as the output clock, the system directly exports the signals of the line clock source and outputs the clock signals through the CITD board. The following line clocks can be output: l l l STM-1 line clock: H801TOPA (configured with the H801CSSA daughter board) or H801TOPA (configured with the H801O2CE daughter board). E1 line clock: H801TOPA (configured with the H801NH1A daughter board) or H801TOPA (configured with the H801EH1A daughter board). Synchronous Ethernet line clock: H801X2CS, H801GSCA, H801GICK, or H801SPUA.
23.2.7.2 Clock Synchronization of the Native TDM Service

The MA5600T/MA5603T can carry native TDM service through GPON and provide multi-E1 end-to-end service. The E1s can be asynchronous with each other. The E1 signals go upstream through the GPON terminal, then undergo the VC12 adaptation and GEM encapsulation, and are then switched to the TOPA board through the GPBD board and the control board. Then, the
23 Clock Feature
TOPA board performs GEM decapsulation and VC12 deadaptation, and implements the E1 upstream transmission or STM-1 upstream transmission through different daughter boards (16 E1 upstream transmission through the NH1A daughter board, and 2 STM-1 upstream transmission through the O2CE daughter board).
Clock Mode 1: System Clock

In this mode, the MA5600T/MA5603T locks the upstream E1 line clock of the TOPA board as the system clock. The system clock signals are issued to the ONU (such as the OT928G, MA5612) through the optical channel provided by the GPON port of the GPBD board. The E1 transmit clock of the ONU synchronizes with the GPON port recovery line clock. Thus, end-toend synchronization is implemented between the upstream E1 of the TOPA board and the downstream E1 of the ONU, as shown in Figure 23-5. Figure 23-5 System locking the E1 line clock of the TOPA board
E1
C I T D
G P B D
S C U
T O P A + N H 1 A Synchronization relation
ONU E1
Service channel
Hardware configuration of the system: l l Board configuration: GPBD, SCU, and TOPA (configured with the NH1A daughter board). Clock configuration: The stratum-3 clock unit is an optional configuration. When the stratum-3 clock unit is configured, the clock quality meets the G.813 requirements; when the stratum-3 clock unit is not configured, the clock quality meets the G.823 traffic requirements.
Key points of the synchronization configuration: l The MA5600T/MA5603T locks an E1 line recovered clock of the TOPA board as the system clock. The device interconnected with the E1 port of the TOPA board is required to serve as the master device, and the E1 port of the TOPA board as the slave device. The transmit clocks of the E1s of the TOPA board need not be configured. They are the VC12 recovery clock by default, and synchronize with the E1 receive clock of the ONU (in the upstream direction).
Issue 01 (2011-10-30)
23 Clock Feature
The transmit clock of the GPON port of the OLT is the system clock by default. The ONU synchronizes with the OLT through the PON port recovery line clock to ensure that the GEM frames are transmitted synchronously. The E1 transmit clock of the ONU adopts the system clock (synchronized with the OLT). It can also adopt the VC12 bit stream recovery clock, which, however, will bring unwanted VC12 adaptation jitter. The device connected to the ONU E1 serves as the slave device and needs to lock the transmit clock of the ONU E1, thus realizing synchronization over the entire network.
Clock Mode 2: Bit Stream Recovery Clock

In this mode, the MA5600T/MA5603T does not lock the upstream E1 clock of the TOPA board. That is, the system clock is asynchronous with the clock of the device interconnected with the E1 port of the TOPA board. The GPBD board issues the system clock signals to the ONU through the optical channel provided by the GPON port for synchronizing the ONU with the OLT. After the TOPA board performs the VC12 adaptation on the E1 bit stream, the signals can be transmitted to the ONU synchronously. The ONU performs the VC12 deadaptation, and recovers the clock of the downstream E1 of the TOPA board (the line receive clock of the TOPA E1). Hence, it can be seen that the E1 transmit clock of the ONU adopts the VC12 bit stream recovery clock, which is asynchronous with the system clock but synchronous with the E1 receive clock of the TOPA. In addition, all the E1s can be adapted and deadapted independently, so the E1s can be asynchronous with each other and can thus be used flexibly. During the VC12 adaptation and deadaptation of the E1s, jitter may occur, as shown in Figure 23-6. Figure 23-6 Auto-adaptation clock recovery
E1
BITS
C I T D
G P B D
S C U
T O P A + N H 1 A Synchronization relation
ONU E1
Service channel VC12 mapping
Hardware configuration of the system: l l Board configuration: GPBD, SCU, and TOPA (configured with the NH1A daughter board) or TOPA (configured with the O2CE daughter board). Clock configuration: The stratum-3 clock unit is an optional configuration. When the stratum-3 clock unit is configured, the clock quality does not meet the G.813 requirements;
Issue 01 (2011-10-30)
23 Clock Feature
when the stratum-3 clock unit is not configured, the clock quality meets the G.823 traffic requirements. Key points of the synchronization configuration: l The system clock of the MA5600T/MA5603T can be randomly configured and is usually asynchronous with the E1 line clock of the TOPA board (this is the typical application; the system clock can also be synchronous with the E1 line clock of the TOPA board). The transmit clocks of the E1s of the TOPA board need not be configured. They are the VC12 recovery clock by default. The transmit clock of the GPON port of the OLT is the system clock by default. The ONU synchronizes with the OLT through the PON port recovery line clock. The E1 transmit clock of the ONU adopts the VC12 bit stream recovery clock. The device connected to the E1 of the ONU needs to lock the E1 transmit clock of the ONU.
l l l l
23.2.7.3 SAToP Clock Synchronization Auto-adaptation recovery mode

Figure 23-7 illustrates the principle of the auto-adaptation clock recovery. In this mode, the receive end recovers the clock of the transmit end through the average arrival rate of the received SAToP packets. As shown in the figure, according to its source clock, the LIU (Line Unit) transmits packets to the destination device. The destination device buffers these packets in a queue, and then sends these packets according to its local clock. A least disparity between the source clock and the local clock of the destination device will cause the depth of the buffer queue of the destination device to change. The depth of the queue can be used to determine whether the local clock is synchronous with the source clock. If the depth of the queue continuously increases, the local clock is behind the source clock. In this case, puts the local clock ahead. If the depth of the queue continuously decreases, the local clock is ahead of the source clock. In this case, puts back the local clock. The purpose of such adjustment is to ensure that the local clock is synchronous with the source clock in the long term. Figure 23-7 Auto-adaptation clock recovery
Data Source node Packets Network Packets Destination Data node Destin clock
LIU
Source clock
LIU
The difficulty point of the auto-adaptation algorithm is that the IP network has inherent delay jitter, the packet delay variation (PDV). PDV can also cause change to the depth of the buffer queue. The destination LIU, however, cannot distinguish whether the change is due to the disparity of frequency or the delay jitter of the IP network, and cannot make a correct reaction. The delay jitter of the IP network is not cumulative and thus can be filtered by certain statistical methods, such as by calculating an average value.
23 Clock Feature
Application of Clock Recovery in the SAToP Service

The MA5600T/MA5603T supports the SAToP application, can recover the clock from the SAToP data streams, and provides the end-to-end E1 service. The E1 access is implemented by the GPON ONU (such as the MA5612). The E1 data is encapsulated as SAToP data, transmitted to the GPBD board, to the control board, and then goes upstream through the TOPA board. The TOPA can implement E1 upstream transmission or STM-1 upstream transmission through different daughter boards (16 E1 upstream transmission through the EH1A daughter board; 2 STM-1 upstream transmission through the CSSA daughter board). The transmit clock mode of each E1 port of the TOPA board is set independently. Different E1 ports can work in different clock modes. Configure the clock mode of the E1 ports according to actual application. Clock mode 1: system clock The E1 port of the TOPA board adopts the system clock as the transmit clock. The line transmit clock of the PON port of the GPBD board is the system clock by default. Therefore, the ONU synchronizes with the system clock of the MA5600T/MA5603T through the PON port, and the E1 port of the ONU adopts the line recovered clock of the PON port as the transmit clock. In this way, global synchronization is implemented from the TOPA E1 to the ONU E1, as shown in Figure 23-8. Figure 23-8 Global synchronization through the system clock
STM-1
C I T D
G P B D
S C U
T O P A + C S S A Synchronization relation
ONU E1
Service channel
Hardware configuration of the system: l l Board configuration: GPBD, SCU, TOPA (configured with the EH1A daughter board) or TOPA (configured with the CSSA daughter board). Clock configuration: The stratum-3 clock unit is an optional configuration. When the stratum-3 clock unit is configured, the clock quality meets the G.813 requirements; when the stratum-3 clock unit is not configured, the clock quality meets the G.823 traffic requirements.
Issue 01 (2011-10-30)
23 Clock Feature
Key points of the synchronization configuration: l Configure the system clock source of the MA5600T/MA5603T. For example, select the BITS clock, the STM-1 line clock, the synchronization Ethernet line clock, or the oscillator as the system clock. Select the system clock as the transmit clock of the E1 ports of the TOPA board. For the STM-1 port, select the tributary E1 transmit clock as the system clock. Therefore, the device interconnected with the E1 port of the TOPA board is required to serve as the slave device, locking the E1 transmit clock of the TOPA board. The transmit clock of the GPON port of the OLT is the system clock by default. The ONU synchronizes with the OLT through the PON port recovered line clock. The E1 transmit clock of the ONU synchronizes with the PON port line clock, thus synchronizing with the system clock of the MA5600T/MA5603T. The device connected to the E1 port of the ONU serves as the slave device, locking the E1 transmit clock of the ONU.
l l l
Clock mode 2: line clock The line clock mode refers to that the E1 line receive clock is adopted as the E1 transmit clock of the TOPA board. In the networking, the port interconnected with the E1 port of the TOPA board is required to serve as the master port. The E1 data received by the upstream port is encapsulated as the SAToP data and transmitted to the ONU through the PON port. The ONU recovers the E1 receive clock of the TOPA board through CESoP, and uses the recovered clock as the E1 transmit clock of the ONU. When the ONU recovers the clock in the SAToP mode, the ONU can choose not to synchronize with the system clock of the MA5600T/MA5603T. As shown in Figure 23-9, the upstream port adopts the line clock, and the ONU port adopts the SAToP recovery clock. Figure 23-9 Line clock synchronization
STM-1 Tributary E1
C I T D
G P B D
S C U
T O P A + C S S A
ONU E1
Synchronization relation SAToP clock Service channel
Hardware configuration of the system:
Issue 01 (2011-10-30)
774
23 Clock Feature
l l
Board configuration: GPBD, SCU, TOPA (configured with the EH1A daughter board) or TOPA (configured with the CSSA daughter board). Clock configuration: The stratum-3 clock unit is an optional configuration. When the stratum-3 clock unit is configured, the clock quality does not meet the G.813 requirements; the quality of the clock recovered from the SAToP auto-adaptation algorithm meets only the G.8261 CES/G.823 traffic requirements. When the stratum-3 clock unit is not configured, the clock quality can meet the G.8261 CES/G.823 traffic requirements.
Key points of the synchronization configuration: l l Configure the system clock source of the MA5600T/MA5603T. For example, select the BITS clock, the STM-1 line clock, or the oscillator as the system clock. Select the E1 line clock as the E1 transmit clock of the TOPA board. For the STM-1 port, select the tributary E1 transmit clock as the tributary line clock. Therefore, the device interconnected with the E1 port of the TOPA board is required to serve as the master device. The transmit clock of the GPON port of the OLT is the system clock by default. The ONU synchronizes with the OLT through the PON port recovered line clock. In the SAToP clock recovery mode, the OLT and the ONU need not always be synchronous. The E1 transmit clock of the ONU adopts the SAToP recovered clock. The device connected to the E1 port of the ONU serves as the slave device, locking the E1 transmit clock of the ONU.
l l
Clock mode 3: recovered clock The recovered clock refers to the E1 clock of the ONU recovered by the OLT in the SAToP mode. In actual application, it is rare to recover the clock of a lower-level device. It applies only to certain special scenarios. The following figure illustrates the GPON device recovering the clock of the ONU in the SAToP mode. The TOPA board of the MA5600T/MA5603T supports one SAToP recovered clock. The TOPA board can recover the E1 clock of the ONU from the upstream SAToP data. The recovered clock can serve as the E1 transmit clock of the TOPA board for implementing synchronization between the upstream E1 port of the TOPA board and the remote E1 port of the OLT, as shown in Figure 23-10. Figure 23-10 Recovered clock
STM-1 Tributary E1
C I T D
G P B D
S C U
T O P A + C S S A
ONU E1
Synchronization relation SAToP clock Service channel
Issue 01 (2011-10-30)
775
23 Clock Feature
Hardware configuration of the system: l l Board configuration: GPBD, SCU, TOPA (configured with the EH1A daughter board) or TOPA (configured with the CSSA daughter board). Clock configuration: The stratum-3 clock unit is an optional configuration. When the stratum-3 clock unit is configured, the clock quality does not meet the G.813 requirements; the quality of the clock recovered from the SAToP auto-adaptation algorithm meets only the G.8261 CES/G.823 traffic requirements. When the stratum-3 clock unit is not configured, the clock quality can meet the G.8261 CES/G.823 traffic requirements.
Key points of the synchronization configuration: l Configure the system clock source of the MA5600T/MA5603T. For example, select the BITS clock, the STM-1 line clock, the synchronization Ethernet line clock, or the oscillator as the system clock. The TOPA board of the MA5600T/MA5603T supports only one SAToP recovered clock. Hence, select the SAToP recovered clock of an E1 port as the SAToP recovered clock source. Select the SAToP recovered clock source as the E1 transmit clock of the TOPA board. For the STM-1 port, select the tributary E1 transmit clock as the SAToP recovered clock source. Therefore, the device interconnected with the E1 port of the TOPA board is required to serve as the slave device, locking the E1 transmit clock of the TOPA board. The transmit clock of the GPON port of the OLT is the system clock by default. The ONU synchronizes with the OLT through the PON port recovered line clock. In the SAToP clock recovery mode, the OLT and the ONU need not always be synchronous. The ONU locks the E1 transmit clock of the lower-level device, and the ONU adopts the line clock as its E1 transmit clock.
23.2.7.4 Clock Synchronization of the Synchronization Ethernet Service

Traditional Ethernet application does not consider the synchronization requirement. The Ethernet ports adopt the 100 ppm local oscillator as the transmit clock, and the transmit clocks of the NEs are independent of each other. As such, the clocks are not precise enough. Synchronization Ethernet is a technology that recovers the clock from the bit streams on the Ethernet link and implements synchronization between Ethernets. The implementation mode is similar to the synchronization mode of the SDH/PDH networks. In the transmit direction, the high-precision system clock is adopted as the transmit clock, which is recovered and obtained at the receive end. The transmission and reception are performed by the physical layer independently, which in terms of function is compatible with traditional Ethernet. The MA5600T/MA5603T supports the 10GE and GE synchronization Ethernet application, and can issue the GE and FE system clock signals. In the transmit direction, the system clock is adopted as the port transmit clock by default, the clock mode of which cannot be changed. In the receive direction, each port recovers the line clock, which serves as an optional clock source of the system. The following interface boards of the MA5600T/MA5603T support synchronous transmission and reception: H801X2CS, H801GSCA, H801GICK, and H801SPUA. l l
Issue 01 (2011-10-30)
The H801X2CS board provides two 10GBASE-R ports. The H801GSCA board provides four 1000BASE-X ports.
23 Clock Feature
l l
The H801GICK board provides two 1000BASE-X ports. The H801SPUA board provides two 10GBASE-R ports and eight 1000BASE-X ports.
Figure 23-11 Clock synchronization of the synchronous Ethernet service

Synchronous Ethernet
BITS
C I T D
O P F A
E T H B
S C U
X 2 C S G I C K C I T D
O P F A
E T H B
S C U
X 2 C S G I C K
Synchronization relation Service channel
Hardware configuration of the system: l l Board configuration: SCU, X2CS (upstream through 10GE), GSCA (upstream through GE) and GICK (upstream through GE), GPBD. Clock configuration: The stratum-3 clock unit is an optional configuration. When the stratum-3 clock unit is configured, the clock quality meets the G.8262 requirements; when the stratum-3 clock unit is not configured, the clock quality meets the G.8261 EEC requirements.
Key points of the synchronization configuration: l Configure the system clock source of the MA5600T/MA5603T. For example, select the BITS clock, the STM-1 line clock, the synchronization Ethernet line clock, or the oscillator as the system clock. By default, the transmit clock of the upstream port and access port of the MA5600T/ MA5603T is adopted as the system clock source. The clock mode cannot be changed and does not need any extra configuration. Only the ports of the X2CS, GSCA, and GICK interface boards support the recovery of the line clock. The line recovered clock can serve as the system clock source. The line recovered clock should be configured in such a way that mutual-locking between NEs is prevented. When lower-level devices need to synchronize with the network clock, the lower-level devices should lock the line clock of the GPBD boards.
Issue 01 (2011-10-30)
777
23 Clock Feature

Glossary
Term Frequency accuracy Explanation Frequency accuracy refers to the degree by which the actual output frequency of signals wanders from the frequency of the ideal clock source. Frequency accuracy is usually presented as a relative frequency tolerance. For example, if the nominal frequency is f0, and the actual frequency is f, the frequency accuracy is (f - f0)/f0. The value is in the unit of ppm or ppb. In the non-locked mode, when the frequency of the input clock approximates a certain range of the central frequency, the clock phase-locked loop will enter the locked mode from the free-run mode or the holdover mode. Such a range is called the pull-in range. In the locked mode, when the frequency of the input clock wanders from a certain range of central frequency, the clock phase-locked loop will enter the holdover mode. Such a range is called the pull-out range. The pullout range does not consider the repeated changes of the input frequency. Wander generation Wander generation refers to the wander value of the output signal when the clock locks a wander-free ideal signal. Wander generation reflects the degradation degree of the input ideal source when the system clock locks an ideal signal. It is usually measured as MTIE and TDEV. Jitter output is generated by the output clock of a device which locks an ideal reference timing signal. Wander tolerance/Jitter tolerance describes the tolerance of the system to the wander and jitter of the input clock source. Noise transfer reflects the capability of the clock in filtering the input wander. After a given input signal with a great wander value undergoes the low-pass processing of the phase-locked system, the output signal should have a smaller wander value.
Pull-in and pull-out ranges
Jitter output
Wander tolerance/Jitter tolerance
Noise transfer
Issue 01 (2011-10-30)
778
23 Clock Feature
Term Long-term phase transient response (holdover)
Explanation The device records the holdover data when locking an external clock source for a long time. When the external clock source is lost, the device provides a system clock source according to the recorded holdover data. A device in such a state enters the holdover mode. The holdover performance reflects the stability of the system against frequency wander within a certain period after the clock source is lost.

Acronym/Abbreviation PDH STM SDH TDM PRC LPR SSU SEC EEC GPS TIE MTIE CES SSM GPON BITS NTR SAToP TOD PPS Full Spelling Plesiochronous digital hierarchy Synchronous transfer mode Synchronous digital hierarchy Time division multiplexing Primary reference clock Local primary reference Synchronization supply unit SDH equipment clock Ethernet equipment clock Global positioning system Time interval error Maximum time interval error Circuit emulation service Synchronization status message Gigabit passive optical network Building integrated timing supply Network time recover Structure-agnostic transport over packet Time of day Pulse per second
Issue 01 (2011-10-30)
779
23 Clock Feature
Acronym/Abbreviation DCLS BMC E2E OC BC TC P2P PTP UTC TLV UDP
Full Spelling DC level shift Best master clock End-to-end Ordinary clock Boundary clock Transparent clock Peer-to-peer Precision Time Protocol Coordinated universal time Type, length, value User Datagram Protocol
Issue 01 (2011-10-30)
780
24 The Feature of LAN Interface Boards
24
The Feature of LAN Interface Boards
About This Chapter

24.1 ETHB Board Feature This topic describes the function, specifications, and principle of the ETHB board feature. 24.2 SPUA This topic describes the features of the SPUA board. 24.3 GIU Board Feature This topic describes the feature of direct connection of the MA5600T/MA5603Ts through the FE or GE ports on the GIU upstream board.
Issue 01 (2011-10-30)
781
24.1 ETHB Board Feature

This topic describes the function, specifications, and principle of the ETHB board feature.
24.1.1 Introduction
Definition
The system supports the ETHB board that is used for multi-GE upstream transmission or Ethernet subtending. This is called the ETHB board feature. The ETHB board is an enhanced Ethernet interface board developed on the basis of the ETHA board. The ETHB board provides eight GE optical/electrical ports for upstream transmission or subtending, and supports the function such as within-board aggregation or cross-board aggregation.
Purpose
With the deployment of the multi-play service and wholesale service, carriers require the access device to provide more upstream ports and high bandwidth, and has higher reliability, so as to meet the networking and application requirements in a multi-edge network. In earlier versions, the upstream transmission of the OLT is implemented by the SCU control board or GIU upstream board. The number of upstream ports, however, is insufficient (for example, two GIU boards provide only four GE ports). The ETHA board is oriented to subtending scenarios and cannot be used for upstream transmission. In addition, the ETHA board does not support within-board self switching or cross-board aggregation. Therefore, when one board fails, the services on all its links will be interrupted. To solve all the preceding problems, Huawei develops the ETHB board that can be used for upstream transmission. The ETHB board can be inserted into any slot for a service board and each EHTB board provides eight GE ports. In this way, the number of upstream ports can be 128 (8 x 16) theoretically. In addition, the ports on different ETHB boards can be aggregated, which improves service reliability. The ETHB board also supports within-board self switching, which meets the requirement of communications between the ports on one board.
Benefits
Benefits to Carriers l The number of upstream ports is sufficient and can be 128 (8 x 16) theoretically. Therefore, upstream ports can be selected according to requirements, thus meeting the requirements for upstream ports of various multi-edge networks. With more upstream ports, a linear increasing upstream bandwidth can be provided. Thus, carriers requirements for bandwidth can be met. The ETHB board can be used as an upstream board or subtend board. When it is used as an upstream board, it supports within-board self switching. When it is used as a subtend board, it supports traffic isolation among users. The ETHB board supports within-board link aggregation and cross-board link aggregation. When one link or board fails, services are not affected. This significantly improves link reliability and system reliability.
l l
Issue 01 (2011-10-30)
Benefits to Users l l The total upstream bandwidth of the system increases and accordingly the peak bandwidth of each user increases. The system reliability improves and therefore more guaranteed services can be provided for users.
l l l l l l l Each ETHB board provides eight GE ports and each GE port supports 4000 VLANs. Each ETHB board supports 32K MAC addresses and the ports are isolated from each other. The ETHB board supports auto-adaptation for the GE transceiver type (optical transceiver or electrical transceiver). The ETHB board supports the query and display of the information about the optical transceiver and electrical transceiver. The ETHB board supports GE port aggregation and protection functions. The ETHB board supports creation of a traffic stream to the control board by using a service port. The ETHB board supports smart SFP optical modules.

The following lists the reference standards and protocols of this feature: l l l IEEE 802.1q: IEEE standards for local and metropolitan area networks-Virtual Bridged Local Area Networks IEEE 802.1s: MSTP IEEE 802.1ad: LACP
24.1.4 Availability
Version Support
Hardware Support
When using the ETHB board to provide the inter-board aggregation function, pay attention to the following points: l l When the MABC or MABH backplane is adopted, two adjacent ETHB boards can be aggregated through the backplane. When another backplane is adopted, two adjacent ETHB boards must be aggregated through the interconnection port.
Issue 01 (2011-10-30)
l l
On the MA5600T, the ID of the slot for a service board starts from 1. Therefore, two ETHB boards in slots 1-2, 3-4, or 5-6, ... can be aggregated. On the MA5603T, the ID of the slot for a service board starts from 0. Therefore, two ETHB boards in slots 0-1, 2-3, or 4-5, ... can be aggregated.
24.1.5 Principle
Upstream Transmission by the ETHB Board
The ETHB board can be used as an upstream board. When an ETHB board is used as an upstream board, it transmits the traffic from user boards to the upper-layer network through the ports on it. Within the ETHB board, the VLAN+MAC forwarding mechanism is adopted for Ethernet traffic. That is, the ingress is learned according to the VLAN ID and the source MAC address carried in the packets, and the egress is searched for according to the VLAN ID and the destination MAC address carried in the packets. Figure 24-1 illustrates the principle of upstream transmission by the ETHB board. Figure 24-1 Principles of upstream transmission by the ETHB board
ETHB upstream board
SCU control board
XPON service board
XPON service board
Traffic direction
When the ETHB board is used as an upstream board, it supports within-board self switching to implement intercommunications between upstream ports. Figure 24-2 illustrates the principle of within-board self switching of the ETHB board when it is used as an upstream board.
Issue 01 (2011-10-30)
784
Figure 24-2 Principles of within-board self switching of the ETHB board when it is used as an upstream board
ETHB upstream board
SCU control board
XPON service board
XPON service board
Traffic direction
Within-Board Aggregation and Cross-Board Aggregation Supported by the ETHB Board

The H801 board supports within-board link aggregation and cross-board link aggregation. This is to increase link bandwidth and to improve link reliability. A link aggregation group can be a manual aggregation group or a static LACP aggregation group. Figure 24-3 illustrates the principle of within-board aggregation. Figure 24-3 Principles of within-board aggregation
Peer device
ETHB upstream board SCU control board
XPON service board
XPON service board
Link aggregation group
Issue 01 (2011-10-30)
785
In the case of cross-board link aggregation, the two adjacent ETHB boards must be bound first, and then any ports on these two boards can be aggregated to form an aggregation group. After a cross-board link aggregation is configured, the system can work normally when partial links or even an entire board fails. In this way, carriers' requirements for higher reliability can be met. Figure 24-4 illustrates the principle of cross-board aggregation. Figure 24-4 Principles of cross-board aggregation
Peer device Aggregation Cross-board aggregation
ETHB service board
ETHB service board
SCU control board
XPON service board
XPON service board
Link aggregation group
24.2 SPUA
This topic describes the features of the SPUA board.
24.2.1 Introduction
Definition
The H801 SPUA board is positioned as an enhanced Layer 2 service processing board of the OLT. The SPUA board provides eight GE ports and two 10GE ports on the front panel. The GE ports support the SFP optical module, and the 10GE ports support the SFP+ optical module.
The SPUA board can be used for transmitting the service upstream and converging the service streams transmitted from lower-level MxUs or DSLAMs. The SPUA board cannot implement the upstream transmission function and the access function at the same time. Being positioned as a convergence and upstream service board, the SPUA board cannot be directly connected to ordinary access users such as PC. The SPUA board supports 16 K service streams (service ports), including switch-oriented service streams and connection-oriented service streams. The Layer 2 services of the SPUA board include the S+C double-tag VLAN switching, and differentiated QoS management based on service stream. In terms of system reliability, the SPUA board supports inter-board aggregation and inter-board protection pair, and supports the LACP and MSTP protocols and networking scenarios. The SPUA board provides multicast upstream ports and subtending ports.
Purpose
After the network position of the OLT is upshifted, the SPUA board can support single-edge and multi-edge convergence, which helps reduce the number of network layers. In addition, the SPUA board supports connection-oriented service streams. With this feature, it can multiplex the same VLAN on different ports, so it can be used for the Open Reach and broadband wholesale services. When it performs S+C forwarding and processes the connection-oriented service streams, the SPUA board is allowed not to learn the MAC address. Hence, the SPUA board can relieve the MAC capacity pressure of the device.
The SPUA board supports the following specifications: l l l l l l l l l l l Provides eight GE ports and two 10GE ports. The SUPA board supports smart SFP optical modules. Supports 16 K service streams, each SPUA port supporting up to 8 K service streams. Supports 32 K MAC addresses, the ports on the front panel being isolated from each other. Supports bi-directional 20 Gbit/s wire speed for forwarding of packets (256 bytes), equal to the 10 Mbit/s PPS processing capability. Supports switch-oriented service streams. Supports cross-connection (connection-oriented service streams). Supports QoS processing. Supports LACP on the port. Supports MSTP on the port. Supports (inter-board) aggregation and protection pair. The SPUA board can also work in the load balancing mode. Supports the protection pair in the time delay mode, not in the port state mode. Supports static configuration and LACP mode for aggregation. Supports the user-side ring check when implementing the access function. Supports the MSTP networking when implementing upstream transmission.
Does not support the Smart Link. Two SPUA boards need to be installed in two adjacent slots when working in the load balancing mode. Does not support protection or aggregation between: the SPUA board and the ports on the front panel of the SCUN board, the SPUA board and the GIU board, or the SPUA board and the ETHA/ETHB board.
NOTE
Create the aggregation group and the protection pair in the following order: Bind the boards first, create the aggregation group, create the protection pair, and then create the service port.
Provides the multicast upstream port when implementing upstream transmission, and provides the multicast subtending port when implementing the aggregation access function. The multicast duplication is based only on the ports of the SPUA board, and not on the service ports. The SPUA board cannot be configured with multicast users. In the case of the SPUA board, the user needs to be configured with a service port (switch-oriented service stream), and C-VLAN = S-VLAN = M-VLAN (the multicast subtending port does not support the M-VLAN switching; if switching is required, the VLAN is switched on the service stream of the multicast user on the lower-level DSLAM). The SPUA board does not support distributed multicast. Supports DHCP option 82 and PPPoE+ for the GPBD<-->SPUA connection-oriented service stream. Supports transparent transmission or block control for the SPUA<-->GPBD BPDU packet. Supports remote packet capture. Supports port mirroring: selecting any of the 10 ports as the destination port, with a maximum of 4 ports among the remaining ports as the source port.
l l l l
24.2.3 Principle
Switch-Oriented Service Stream
The following features are supported for switch-oriented service streams: traffic classification, VLAN switching, VLAN forwarding, and Layer 2 interoperation. l The SPUA board performs traffic classification based on the port VLAN and the user side VLAN (including double-tag user side VLAN), and supports holistic VLAN switching policies, including: S+CS'+C' S+CS' CS CS+C'
NOTE
S, C, S', and C' indicate VLANs. The "SVLAN+CVLAN" double-tag VLAN is an extension to VLANs. It not only expands the VLAN range, but also indicates different meanings by S and C. For example, it indicates service by S, and customer by C. Thus, each "SVLAN+CVLAN" uniquely identifies the type of service for each user, and SVLAN+CVLAN forwarding and switching can be implemented.
The SPUA board supports the private-line service and can transparently transmit all packets. The VLAN switching policies of the TLS private line include adding one tag, adding two tags, transparently transmitting the user side VLAN tag, switching the user side
Issue 01 (2011-10-30)
VLAN tag, switching the VLAN tag into two VLAN tags, and switching the double-tag user side VLAN. l l The SPUA board supports different forwarding modes for different VLANs, such as the VLAN+MAC and the S+C forwarding modes. The SPUA board works with the SCUN control board to support the VLAN-based Layer 2 interoperation. The boards supporting Layer 2 interoperation include the GPBD and SPUA boards. The SPUA board works with the SCUN control board to support the priority of MAC address learning. The network side MAC address is learned with priority. This is to prevent the gateway MAC address from being forged by an illegal user.
If the SVLANs or S+C VLANs of two service ports are the same, the switching domain can be identified by S or S+C. The examples are the VLAN switching processes in the GPON access and the upstream transmission by the SPUA board, as shown in Figure 24-5. Figure 24-5 Switch-oriented service stream
GPBD CVLAN 1 CVLAN 2 CVLAN 3 SCU S or S+C SPUA S S+C S+C
Connection-Oriented Service Stream

Connection-oriented service stream includes service streams with specified source and destination. l The source and the destination can be identified through the traffic classification supported by the board. For example, to create a connection-oriented service stream between the GPBD board and the SPUA board: On the GPON side: frame/slot/port+ONT ID+GEM port, CVLAN SPUA side: frame/slot/port, S+C l l The MAC address of a connection-oriented service stream is not learned. The boards of the current version supporting the connection-oriented service stream include: GPBD as accessSPUA as upstream SPUA as convergenceSPUA as upstream A transparent channel is formed between the user side port and the network side port. Packets are transparently transmitted through this channel. Different ports can use the same VLAN without interfering with each other. On this channel, the MAC address needs not be learned, as shown in Figure 24-6.
Issue 01 (2011-10-30)
789
Figure 24-6 Connection-oriented service stream

GPBD CVLAN 1 CVLAN 2 CVLAN 3 SCU S or S+C SPUA S S+C S+C
QoS
The SPUA board supports simple HQoS for implementing hierarchical scheduling between port, port+SVLAN, and service stream. Here, the port refers to a port on the front panel of the SPUA board, the SVLAN refers to a service VLAN, and the service stream refers to the same service to which different users subscribe. Through QoS, the SPUA board ensures that fair scheduling is implemented on different users and different services. The purpose of HQoS is to ensure fair scheduling between different channels, as shown in Figure 24-7. Figure 24-7 Simple HQoS
The SPUA board supports priority remarking. For details on the remarking methods, see Table 24-2.
Issue 01 (2011-10-30)
790
Table 24-2 Priority processing of the service stream from the SPUA board to the control board From SPUA Board to Control Board CS' 802.1p Priority of Outer VLAN Tag After Switching Specified Copied from the outer VLAN (C) tag at the ingress Copied from the IP precedence CS'+C' Specified Copied from the outer VLAN (C) tag at the ingress Copied from the IP precedence S+CS' Specified Copied from the outer VLAN (S) tag at the ingress Copied from the IP precedence S+CS'+C' Specified Copied from the outer VLAN (S) tag at the ingress Copied from the IP precedence UntaggedS' Untagged S'+C' Specified Specified Specified Copied/Mapped from the outer VLAN (C) tag at the ingress Specified Copied/Mapped from the outer VLAN (C) tag at the ingress 802.1p Priority of Inner VLAN Tag After Switching -
Specified
Currently, to meet the requirements of priority mapping, the system supports four 802.1p priority mapping tables. In the first priority mapping table, mappings 0-0, 1-1, ... 7-7 are constant, that is, the priority is copied. The other three priority mapping tables can be customized by users; for example, mappings 0-0, 1-1, 2-2, 3-3, 4-3, 5-3, 6-3, and 7-3 can be configured. The SPUA board supports scheduling at the egress of packets. Three queue scheduling modes are supported: PQ, WRR, and PQ+WRR. The queuing rules are as follows: The priority is of a specified value (the local priority of the service stream). The packet at the egress is trusted if its outer (or single) tag priority is remarked.
The SPUA board does not support ACL or port mirroring. It supports the board-level packet filtering, wire speed setting, traffic limitation, priority remarking, traffic re-directing, and traffic measurement.
Issue 01 (2011-10-30)
791
24.3 GIU Board Feature

This topic describes the feature of direct connection of the MA5600T/MA5603Ts through the FE or GE ports on the GIU upstream board.
24.3.1 Introduction
Definition
Subtending through GIU boards refers to a networking mode in which the MA5600T/ MA5603T series are directly connected to each other through the FE/GE port on the upstream GIU board.
Purpose
Subtending through GIU boards makes the networking of the MA5600T/MA5603Ts more flexible, and saves the upstream optical fiber resources of the access node. In addition, remote subtending saves the convergence devices at the central office (CO), simplifies topology, and facilitates service configuration.
l The MA5600T/MA5603T can provide subtending through the ports on the GIU board, the SCU control board, or the ETHB board. The SCUB board provides four GE optical ports, which can be used as upstream ports or subtending ports. The SCUN board provides four GE optical ports, which can be used as upstream ports or subtending ports. The ports provided by GIU boards can be used as upstream ports or subtending ports. The ports provided by ETHB boards can be used as subtending ports or upstream ports. When the ports are used as upstream ports, they are used to receive multicast streams. Each ETHB board provides eight ports. The system can be configured with up to 16 ETHB boards, and therefore can provide 128 ports. l l In the case of subtending in an RSTP/MSTP ring topology, the recommended number of nodes is less than seven. When the MA5600T/MA5603T subtends the MA5606T, the MA5600T/MA5603T can subtend the MA5606T through the ports on the GIU board, the SCU control board, or the ETHB board in the master subrack.

The following is the reference standard of this feature: IEEE 802.1w Rapid Spanning Tree
Issue 01 (2011-10-30)
792
24.3.4 Availability
License Support
The feature of subtending through GIU boards is a basic feature of the MA5600T/MA5603T. Therefore, no license is required to access the corresponding service.
Version Support
Feature Dependence
The GIU upstream board has the following feature dependence: l The GICD board works with the control board of GE platform. Each GICD board provides four GE SFP optical ports. The GE electrical port is provided after optical-electrical conversion. The GSCA board works with the control board of GE platform. Each GSCA board provides four GE SFP optical ports and supports synchronizing the Ethernet clock. The X2CS board works with the control board of 10GE platform and supports synchronizing the Ethernet clock. Each X2CS board provides two 10GE SFP optical ports. The GICF board works with the control board of 10GE platform. Each GICF board provides two GE SFP optical ports. The GE electrical port is provided after optical-electrical conversion. The GICK board works with the control board of 10GE platform and supports synchronizing Ethernet clock through the GE port. Each GICK board provides two GE SFP optical ports.
l l l
24.3.5 Principle
According to the device location, subtending supported by the MA5600T/MA5603T can be local subtending or remote subtending.
Local Subtending
Local subtending refers to the subtending of multiple MA5600T/MA5603T subracks that are in a cabinet or in multiple local cabinets. The local subtending of MA5600T/MA5603Ts can be implemented through the control board or GIU upstream board. Each GIU upstream board provides up to four GE optical ports for upstream transmission or subtending. The number of the ports for subtending depends on the bandwidth requirement. If an active/standby configuration is required, configure two GIU upstream boards.
l l l
According to the connection type, local subtending can be in a star topology or in a daisy chain topology. According to the configuration of the two GIU upstream boards, local subtending can be implemented through a single GIU upstream board or through dual GIU upstream boards. The local subtending in a star topology is shown in Figure 24-8 and Figure 24-9. The local subtending in a daisy chain topology is shown in Figure 24-10 and Figure 24-11.
Figure 24-8 Local subtending in a star topology (MA5600T)
Splitter S C U S C U S C U S C U Splitter S C U S C U S C U S C U
To another shelf
Splitter
To another shelf
One GIU board in a shelf
Two GIU boards in a shelf
Issue 01 (2011-10-30)
794
Figure 24-9 Local subtending in a star topology (MA5603T)

SCU SCU
SCU SCU
To another shelf Two GIU boards in a shelf
Splitter
SCU SCU
SCU SCU
Splitter
Splitter
To another shelf
NOTE
Optical splitters are required for local subtending in the case of the configuration of dual GIU upstream boards.
Issue 01 (2011-10-30)
795
Figure 24-10 Local subtending in a daisy chain topology (MA5600T)

Splitter S C U S C U S C U S C U Splitter S C U S C U S C U S C U
To another shelf
Splitter
To another shelf
Two GIU boards in a shelf
Issue 01 (2011-10-30)
796
Figure 24-11 Local subtending in a daisy chain topology (MA5603T)

SCU SCU
SCU SCU
To another shelf Two GIU boards in a shelf
Splitter
SCU SCU
SCU SCU
Splitter
Splitter
To another shelf
Remote Subtending with a Control Device

Remote subtending (with a control device) refers to the subtending mode in which the control MA5600T/MA5603T subtends the remote MA5600T/MA5603T or other mini DSLAMs such as the MA5606T through optical fibers. In remote subtending (with the control device), the port on the control board or GIU board can be used for subtending. The control board and GIU board support up to eight ports. If the number of subtending ports is insufficient, an additional ETHA or ETHB board can be added to provide subtending ports. For example, as shown in Figure 24-12and Figure 24-13, the ETHA/ETHB board is used for subtending the remote MA5600T/MA5603T.
Issue 01 (2011-10-30)
797
Figure 24-12 Remote subtending with a control device (MA5600T)

Local subtending S S C C U U
Remote subtended S C U S C U
S S C C U U
Remote subtended MA5606T MPW MCU
Figure 24-13 Remote subtending with a control device (MA5603T)

Remote subtended
Splitter
SCU SCU
SCU SCU
Splitter
Remote subtended
Remote subtended MA5606T MPW SCU SCU MCU
Issue 01 (2011-10-30)
798
When the devices have the control module, remote subtending can also be implemented in an MSTP/RSTP ring topology, as shown in Figure 24-14 and Figure 24-15. In this application, the control board, the GIU board, and the ETHA/ETHB subtending board all support the subtending in an MSTP ring topology; however, the ETHA/ETHB board can be configured only on the device that is connected to the CO device and provides upstream ports. A more complicated subtending network is an MSTP/RSTP ring network in which each node is involved in local or remote subtending. Figure 24-14 Remote subtending in an MSTP/RSTP ring topology (MA5600T)
ETH S C U S C U
S C U
S C U
Issue 01 (2011-10-30)
799
Figure 24-15 Remote subtending in an MSTP/RSTP ring topology (MA5603T)
SCU SCU
SCU SCU
SCU SCU
SCU SCU

Glossary
Table 24-4 Glossary of the terms related to the subtending network feature Term Local subtending Description Subtending of multiple subracks that are in the same cabinet, or subtending of multiple subracks that are in different local cabinets Subtending of remote subracks or other mini DSLAMs through optical fibers
Remote subtending

Table 24-5 Acronyms and abbreviations of the subtending networking feature Acronym/Abbreviation RSTP
Issue 01 (2011-10-30)
Full Spelling Rapid Spanning Tree Protocol
800
Acronym/Abbreviation MSTP
Full Spelling Multiple Spanning Tree Protocol
Issue 01 (2011-10-30)
801

MA5600T&amp;MA5603T V800R010C00 Feature Description

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MA5600T&amp;MA5603T V800R010C00 Feature Description

Enviado por

Direitos autorais:

Formatos disponíveis

SmartAX MA5600T/MA5603T Multi-service Access Module V800R010C00

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

About This Document

About This Document

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

About This Document

Updates in Issue 01 (2011-10-30)

The following information is modified:

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

2 P2P Optical Access......................................................................................................................30

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

3.6 Glossary, Acronyms, and Abbreviations..........................................................................................................53

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

9 Layer 2 Protocol Handling.......................................................................................................157

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

14 Network Protection Features.................................................................................................474

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

16 Device Management Security...............................................................................................618

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

19 Line Optimization and Line Test.........................................................................................692

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

20 Operation and Maintenance..................................................................................................703

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

22 Redundancy Backup of the Control Boards.......................................................................753

24 The Feature of LAN Interface Boards..................................................................................781

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

The ODN connects the OLT to the ONU.

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

The system supports the following GPON QoS specifications:

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

1.3 Reference Standards and Protocols

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

1.5 Overview of the GPON System

Passive Optical Splitter

Passive Optical Splitter

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

Introduction to the GPON System

ODN OLT 1310nm ONU/ONT

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SmartAX MA5600T/MA5603T Multi-service Access Module Feature Description

1 ONU1 2 ONU2 3 ONU3 2

1.6 GPON Principle

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

MA5600T&MA5603T V800R010C00 Feature Description

MA5600T&MA5603T V800R010C00 Feature Description