idnits 2.17.1 draft-zhang-l3vpn-label-sharing-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2014) is 3600 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 161, but not defined == Missing Reference: 'RFC3031' is mentioned on line 272, but not defined == Missing Reference: 'RFC5305' is mentioned on line 684, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6571 (ref. 'LFA') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Proposed Standard Peng Zhou 4 Expires: December 18, 2014 Huawei 5 Russ White 6 IETF 7 June 16, 2014 9 Label Sharing for Fast PE Protection 10 draft-zhang-l3vpn-label-sharing-02.txt 12 Abstract 14 This document describes a method to be used by VPN Service Providers 15 to provide multi-homed CEs with fast protection of egress PEs. Egress 16 PEs in a redundant group always share the same label in distribution 17 of VPN routes of a VRF. A virtual Next Hop (vNH) in the IGP/MPLS 18 backbone is created as the common end of LSP tunnels which would 19 otherwise terminate at each egress PE. Primary and backup LSP tunnels 20 ended at the vNH are set up by MPLS on basis of existing IGP FRR 21 mechanisms. If the primary egress PE fails, the backup egress PE can 22 recognize the "shared" VPN route label carried by the data packets. 23 Therefore, the failure affected data packets can be smoothly rerouted 24 to the backup PE for delivery without changing their VPN route label. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Conventions used in this document . . . . . . . . . . . . . 4 66 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. The Virtual Next Hop . . . . . . . . . . . . . . . . . . . . . 4 68 3. Link Costs Set Up for IGP FRR . . . . . . . . . . . . . . . . . 5 69 4. The LSP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. The VPN Route Label . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. Sharing the VPN Route Label . . . . . . . . . . . . . . . . 6 72 5.1.1. Option A: Reserved Label Ranges per RG . . . . . . . . 7 73 5.1.2. Option B: The Label Swapping Table . . . . . . . . . . 7 74 5.2. Binding to LSP Tunnels . . . . . . . . . . . . . . . . . . 8 75 6. Examples To Walk Through . . . . . . . . . . . . . . . . . . . 8 76 6.1. Label Distribution Procedure . . . . . . . . . . . . . . . 8 77 6.2. Protection Procedure . . . . . . . . . . . . . . . . . . . 9 78 7. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7.1. Label Space Management for Option A . . . . . . . . . . . . 9 80 7.2. Backup LSP Tunnel Exceptions . . . . . . . . . . . . . . . 10 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 83 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 87 Appendix A: Generating OSPF LSAs . . . . . . . . . . . . . . . . . 11 88 Appendix B: Generating ISIS LSPs . . . . . . . . . . . . . . . . . 13 89 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 For the sake of reliability, ISPs often connect one CE to multiple 94 PEs. When the primary egress PE fails, a backup egress PE continues 95 to offer VPN connectivity to the CE. If local repair is performed by 96 the upstream neighbor of the primary egress PE on the data path, it's 97 possible to achieve a 50msec switchover. 99 VPN routes learnt from CEs are distributed by egress PEs to ingress 100 PEs that need to know these VPN routes. Egress PEs in a redundant 101 group (RG) MUST advertise the same VPN route label for routes of the 102 same VPN. When the primary egress PE fails, data packets are 103 redirected to a backup egress PE by the PLR (Point of Local Repair) 104 router, the backup PE can recognize the VPN route label in these data 105 packets and deliver them correctly. The method developed in this 106 document is so called "Label Sharing for Fast PE Protection". 108 1.1. Overview 110 +====================================+ 111 +---+ | +---+ +--+ +---+ M | 112 |CE1+----+PE1+----+P1+----+PE3+-------+ | 113 +---+ | +-+-+ +-++ +---+ 1100| | 114 | | | | +-+-+ | +---+ 115 | | | | +vNH+----+CE2| 116 | | | | +-+-+ | +---+ 117 +---+ | +-+-+ +-++ +---+ 1100| | 118 |CE3+----+PE2+----+P2+----+PE4+-------+ | 119 +---+ | +---+ +--+ +---+ S | 120 | | 121 | IGP/MPLS Backbone Network | 122 +====================================+ 124 Figure 1.1: Egress PE routers share the same VPN route label 1100. 126 An example topology is shown in Figure 1.1. Let PE1 and PE2 be 127 ingress routers, and let PE3 and PE4 be egress routers. CE2 is 128 connected to both PE3 and PE4 so they form an Redundant Group (RG). 129 Usually, egress PEs may be configured to be in the same RG or 130 discover each other from the CE routes learning process which can be 131 a dynamic routing algorithm or a static routing configuration 132 [RFC4364]. Suppose PE3 is the primary while PE4 is the backup. For 133 topologies with more than two egress PEs in an RG, one PE acts as the 134 primary while other act as backups. 136 A vNH node is created in the backbone. The primary PE allocates a 137 loopback IP address to vNH (say 2.2.2.2). Instead of the egress PEs, 138 vNH acts as the common end node of LSP tunnels which otherwise end at 139 egress PEs. The metrics ('M' and 'S') for the links between egress 140 PEs and vNH is set up in a way that the primary and backup LSP 141 tunnels to vNH respectively use PE3 and PE4 as the penultimate hop. 143 Egress PEs in an RG MUST advertise the same VPN route label for each 144 VPN connected to this RG. When a route is learn from CE2 (say 145 10.9.8/24), PE3 and PE4 will distribute this route to other PEs 146 sharing the same label (say 1100). In this way, when the primary PE 147 fails, the VPN route label carried with the rerouted data packets 148 need not be changed. It can be recognized by the backup PE as well. 150 This document supposes BGP/MPLS IP VPN [RFC4364] is deployed in the 151 backbone and Label Distribution Protocol (LDP) is used to distribute 152 MPLS labels. The approach developed in this document confines changes 153 to routers in an RG. P and PE routers out of this RG are totally 154 oblivious to these changes. 156 1.2. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 1.3. Terminology 164 VRF: Virtual Routing and Forwarding table [RFC4364] 166 FRR: Fast ReRouting 168 PLR: Point of Local Repair 170 LFA: Loop-Free Alternate [LFA] 172 RG: Redundant Group. A Redundant Group of Provider Edge nodes (PEs) 173 to which a set of CEs are multi-homed. 175 2. The Virtual Next Hop 177 A virtual router (the virtual Next Hop, vNH) is created in IGP to 178 represent the RG in the Service Provider's backbone. For other 179 routers in the backbone, the vNH acts as the common egress PE 180 connecting a set of CEs. Multiple vNHs may be created for one RG. 181 Then multiple paths can be computed from ingress PEs to the vNHs. 182 Ingress PEs can choose from these paths to achieve load balance for 183 the CEs. 185 Service Providers may configure one PE to be the primary when an RG 186 is created. The primary PE may also be automatically elected out of 187 the RG in the same way the DR is selected (see section 7.3 of 188 [RFC2328]), or the DIS is selected [ISIS]. Other PEs in the RG will 189 act as backup ones. This primary PE determines the loopback IP 190 address for the vNH. This loopback IP address can be configured 191 manually or assigned automatically. The SystemID of the vNH under 192 ISIS is composed based on this loopback IP address. The primary PE 193 generates the router link state information (LSA/LSP) on behalf of 194 the vNH. Links to each PE and each CE in the group are included in 195 router link state information PDUs of the PE and CE. 197 The overload mode MUST be set so that the rest routers in the network 198 will not route transit traffic through the vNH. In OSPF, the overload 199 mode can be set up through setting the link weights from the vNH to 200 egress PEs to the maximum link weight which is 0xFFFF. In ISIS, this 201 overload mode is realized as setting the overload bit in the LSP of 202 the vNH. (See Appendix A and B for the detail set up of LSAs/LSPs.) 204 3. Link Costs Set Up for IGP FRR 206 |<------ Sxy3-------->| 208 +-------Px(PLR)-------PE3 209 | | \ M 210 | | \ 211 Pxy C34| vNH 212 | | / 213 | | / S 214 +---------------------PE4 216 |<------ Sxy4-------->| 218 Figure 2.2: The illustration of equations. 220 If the IGP costs for the links between egress PEs and the vNH can be 221 set up in a way that one egress PE appears on the primary path while 222 the other PE appears on the backup path, the PLR can make use of the 223 multiple egress PEs to achieve fast failure protection. Link weights 224 can be set up according to the following rule in order to leverage 225 the well supported [LFA] as the IGP FRR mechanism. 227 1. This document supposes bidirectional link weights are being used. 228 As illustrated in Figure 2.2, assume the weight for the link between 229 PE3 and vNH is "M" and the weight for the link between PE4 and vNH is 230 "S". The weight for the link between PE3 and PE4 is C34. 232 2. Px is a neighbor of PE3. This Px will act as the PLR. Suppose Pxy 233 is Px's neighbor with the shortest path to PE4, after PE3 is removed 234 from the topology. The cost of this path is Sxy4. 236 3. Add PE3 back to the topology. The cost of the path from Pxy to PE3 237 is Sxy3. 239 4. "M" and "S" can be set up as long as the following two equations 240 hold. 242 eq1: Sxy4+S < Sxy3+M 244 eq2: C34+S > M 246 The eq1 guarantees that Pxy is safe, i.e., no loop occurs, to be used 247 as the next hop by the PLR for bypass. The eq2 is designed to insure 248 that the primary path does not go through the primary egress PE and 249 backup egress PE in series. 251 Although this document designs the method based on [LFA] which is 252 widely deployed, other IGP FRR mechanisms can also be utilized to 253 achieve the protection. For example, [MRT] can be applicable 254 regardless of how the link weights are set up. 256 4. The LSP Tunnels 258 Egress PEs use the IP address of the vNH to identify the FEC. Its 259 LSPs on basis of IGP routes with vNH as the last hop are set up using 260 LDP: 262 - The primary LSP tunnel follows the IGP route from ingress PEs to 263 the vNH; 265 - The backup LSP tunnel is set up according to existing IGP FRR 266 calculation, such as [MRT] and [LFA]. 268 Data packets are tunneled through the backbone using a "tunnel label" 269 at the top of the label stack. Egress PE will not really transmit a 270 packet to the tunnel end node vNH. Rather, they need locally deliver 271 the packet. It can be interpreted that at the egress PE, the packet's 272 next hop is the egress PE itself (see Section 3.10 of [RFC3031]). The 273 tunnel label will be popped at the egress PE. The indication for 274 popping is got from the tunnel label at the top of the stack since 275 this is a label assigned to the FEC identified by the PE's loopback 276 IP address. Next, there will be a pop of the VPN route label followed 277 by an address lookup in the VRF. Section 5 will explain how to set 278 the VPN route label in order to leverage these LSP tunnels to achieve 279 the egress PE protection. 281 5. The VPN Route Label 283 5.1. Sharing the VPN Route Label 284 In [RFC4364], egress PEs separately allocate and distribute the label 285 for the route to an address prefix they learn from CEs. In this 286 document, it's REQUIRED that backup PE(s) in an RG always advertises 287 the label already advertised by the primary PE for the address prefix 288 in question. The primary PE RG SHOULD distribute the same label for 289 any address prefix in an attached VPN. This is per VRF label sharing. 290 Others granularities, such as per address family per VRF label 291 sharing, are also feasible. 293 Egress PEs continue to locally allocate VPN route labels so that the 294 proposal need not modify existing forwarding processes of L3VPN 295 egress PEs. At the backup egress PE, the allocated label and the 296 distributed label would be inconsistent. The following two options 297 arise to address this issue. 299 5.1.1. Option A: Reserved Label Ranges per RG 301 PEs in an RG are physically connected to the same set of CEs. It's 302 viable for them allocate the same VPN route label per VPN. For each 303 VPN served by an RG, the backup egress PE always allocates the same 304 label as the primary PE. It acts as a 'compromised' network entity 305 which always listens to the label advertised by the primary then 306 allocates and also distributed the same label. By doing this, they 307 are intimating the VPN route label allocation of the virtual node, 308 vNH. 310 For this option, PEs in an RG are REQUIRED to reserve the same label 311 range(s) for allocation at the management plane. PEs with h/w 312 disjoint label ranges are not qualified for this option. This option 313 SHOULD only be used in well managed and highly monitored networks. 314 It's not intended to be applicable when the RG spans more than one 315 administrative domain. It ought not to be deployed on or over the 316 public Internet. 318 Note that if one PE participates in multiple RGs, a label range 319 reserved for one RG can't be used by another RG on this PE. It 320 increases the consumption of labels on this PE. So this option should 321 be deployed with care in this case. 323 The architecture of the label sharing method allows a 'higher-layer' 324 entity to allocate labels for all PEs across all RGs. This document 325 leaves this choice as for future study. 327 5.1.2. Option B: The Label Swapping Table 328 +----+----+ 329 |1100| 30 | 330 |1101| 31 | 331 |1102| 32 | 332 . . 333 . . 334 . . 335 +----+----+ 337 Figure 2.3: The label 'swapping' table 339 In the inter-AS L3VPN Option B defined in Section 10 of [RFC4364], 340 when an ASBR distributes a VPN route to an ASBR in another AS, it 341 need perform a label swap for this route. Similarly, the backup PE in 342 this proposal uses a label swapping table to record the mapping 343 between advertised labels and locally assigned labels for VPN routes. 344 Obviously, the backup PE need maintain one such table per RG. 345 Whenever a data packet to a route in a VPN attached to the RG arrives 346 at the backup PE, the locally assigned label (e.g., 30) got from the 347 swapping will be used in the VPN route label lookup followed by an 348 address lookup. 350 5.2. Binding to LSP Tunnels 352 When the VPN route with a shared label is distributed to other PEs by 353 the primary PE and backup PEs, the BGP next hop is set to the IP 354 address of the vNH. As defined in Section 4, LSP tunnels are set up 355 for the FEC identified also by the IP address of the vNH. By doing 356 this, the VPN route is bound to these LSP tunnels. When data packets 357 to this VPN route are tunneled through the backbone, these LSP 358 tunnels will offer the protection. 360 6. Examples To Walk Through 362 Two examples are included in this section. Figure 1.1 is referred. 363 The first one describes how to distribute VPN route label to peers. 364 It's westbound in the control plane. The second one interprets how 365 egress PE act in the case of the primary PE failure. It's eastbound 366 in the data plane. 368 6.1. Label Distribution Procedure 370 Assume PE3 is elected as the primary while PE4 is the backup. The 371 loopback IP address of vNH is 2.2.2.2. 373 1) PE3 learns the VPN route to address prefix 10.9.8/24 from CE2. It 374 allocates the VPN route label 1100 and distributes it in BGP with 375 2.2.2.2 as the BGP Next Hop. (prefix = 10.9.8/24|label = 1100|BGP 376 Next Hop = 2.2.2.2) 378 2) PE4 also learns the VPN route to address prefix 10.9.8/24 and 379 allocate the VPN route label 30. It then waits for the primary PE3 380 to advertise the VPN route label for this prefix. 382 3) PE4 monitors the VPN route label 1100 from PE3 for the prefix 383 10.9.8/24. The mapping from 1100 to 30 is inserted to the swapping 384 table. 386 4) PE4 distributes the VPN route using the monitored label 1100. 387 (prefix = 10.9.8/24|label = 1100|BGP Next Hop = 2.2.2.2) 389 6.2. Protection Procedure 391 Suppose the label for the primary LSP tunnel to vNH is 2100 while the 392 backup LSP tunnel to vNH is 3100. P1 is the PLR. 394 1) In normal case, P1 sends data packets with tunnel label 2100 to 395 PE3. When PE3 fails, P1 redirects data packets to the backup LSP 396 tunnel (say P2-PE4-vNH) using tunnel label 3100. 398 2) PE4 will receive a packet with two levels of labels. It pops the 399 outer label 3100 and use this label to identify a swapping table. 401 3) PE4 pops the VPN route label and looks up the swapping table. The 402 VPN route label 1100 is mapped to 30. 404 4) The VPN route label 30 is looked up in the VPN route label table 405 followed by an address lookup in the VRF. 407 7. Operations 409 7.1. Label Space Management for Option A 411 A label range should be reserved before an RG comes to operate. 412 Operators need set a large label sharing space for label ranges 413 reservation. When an RG is created, the operator needs reserve a 414 unused label range for it. The label range should be reserved in a 415 manner of 'enough is enough'. If a label range of an RG is being used 416 out, the operator can reserve a new range from the unused label 417 sharing space. The newly reserved range is then appended to the one 418 being used out. 420 If a backup PE is partitioned from the primary PE, it continues to 421 work with those allocated labels for the RG. However, it MUST NOT 422 allocate any more labels in the reserved ranges. A label in a 423 reserved range can only be allocated by a backup PE when it monitors 424 that the primary PE has distributed this label. 426 When a primary PE resumes from a failure, its reserved label ranges 427 come to work again. It SHOULD conserve the labels it allocated for 428 each range. 430 7.2. Backup LSP Tunnel Exceptions 432 The label sharing method requires that the backup LSP tunnel is set 433 up as specified in Section 4, following the IGP route. However, 434 Service Providers are allowed to have exceptions. For instance, an 435 operator may use BGP Local_Pref to give a higher degree of preference 436 to the route advertised by the primary PE. For another instance, the 437 operator may have the primary PE advertise a more specific prefix. 438 Take Figure 1.1 for example, the backup tunnel will actually goes 439 through PE4->PE3->CE2 for both instances. When the VPN route is bound 440 to this tunnel, it does not protect the primary egress PE. An alarm 441 should be generated to notify the operator that such kind of 442 configuration will jeopardize the VPN route's resilience to egress PE 443 node failure. 445 8. Security Considerations 447 This document raises no new security issues. 449 9. IANA Considerations 451 This document requires no IANA actions. RFC Editor: please remove 452 this section before publication. 454 Acknowledgements 456 Authors would like to thank the comments and suggestions from Bruno 457 Decraene, Eric Rosen, Eric Gray, Jakob Heitz, James Uttaro, Jeff 458 Tantsura, Loa Andersson, Nagendra Kumar, Robert Raszuk, Stewart 459 Bryant, Shunwan Zhuang, Wim Henderickx and Zhenbin Li. 461 10. References 463 10.1. Normative References 465 [LFA] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, 466 B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 467 Alternate (LFA) Applicability in Service Provider (SP) 468 Networks", RFC 6571, June 2012. 470 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 471 Networks (VPNs)", RFC 4364, February 2006. 473 [ISIS] ISO, "Intermediate system to Intermediate system routeing 474 information exchange protocol for use in conjunction with 475 the Protocol for providing the Connectionless-mode Network 476 Service (ISO 8473)," ISO/IEC 10589:2002. 478 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 480 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 481 for Network Management of TCP/IP-based internets:MIB-II", 482 STD 17, RFC 1213, March 1991. 484 10.2. Informative References 486 [MRT] A. Atlas, Ed., R. Kebler, et al, "An Architecture for 487 IP/LDP Fast-Reroute Using Maximally Redundant Trees", 488 draft-ietf-rtgwg-mrt-frr-architecture, work in progress. 490 Appendix A: Generating OSPF LSAs 492 The following Type 1 Router-LSA is flooded by the egress PE with the 493 highest priority. As defined in [RFC2328], this LSA can only be 494 flooded throughout a single area. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | LS age | Options | LS type | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Link State ID | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Advertising Router | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | LS sequence number | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | LS checksum | length | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | 0 |V|E|B| 0 | # links | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Link ID | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Link Data | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Type | # TOS | metric | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | ... | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | TOS | 0 | TOS metric | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Link ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Link Data | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | ... | 527 LS age 528 The time in seconds since the LSA was originated. (Set to 0x708 529 by default.) 531 Options 532 As defined in [RFC2328], options = (E-bit). 534 LS type 535 1 537 Link State ID 538 Same as the Advertising Router 540 Advertising Router 541 The Router ID of the vNH. 543 LS sequence number 544 As defined in [RFC2328]. 546 LS checksum 547 As defined and computed in [RFC2328]. 549 length 550 The length in bytes of the LSA. This includes the 20 byte LSA 551 header. (As defined and computed in [RFC2328].) 553 VEB 554 As defined in [RFC2328], set its value to 000. 556 #links 557 The number of router links described in this LSA. It equals to 558 the number of Egress PEs in the RG. 560 The following fields are used to describe each router link connected 561 to an egress PE. Each router link is typed as Type 1 Point-to-point 562 connection to another router. 564 Link ID 565 The Router ID of one of the egress PEs in the RG. 567 Link Data 568 It specifies the interface's MIB-II [RFC1213] ifIndex value. It 569 ranges between 1 and the value of ifNumber. The ifNumber equals to 570 the number of the PEs in the RG. The PE with the highest priority 571 sorts the PEs according to their unsigned integer Router ID in the 572 ascend order and assigns the ifIndex for each. 574 Type 575 Value 1 is used, indicating the router link is a point-to-point 576 connection to another router. 578 # TOS 579 This field is set to 0 for this version. 581 Metric 582 It is set to 0xFFFF. 584 The fields used here to describe the virtual router links are also 585 included in the Router-LSA of each egress PEs. The Link ID is 586 replaced with the Router ID of the vNH. The Link Data specifies the 587 interface's MIB-II [RFC1213] ifIndex value. The "Metric" field is set 588 as defined in Section 3. 590 Appendix B: Generating ISIS LSPs 592 The primary egress PE generates the following level 1 LSP to describe 593 the vNH node. 595 No. of octets 596 +-------------------------+ 597 | Intradomain Routeing | 1 598 | Protocol Discriminator | 599 +-------------------------+ 600 | Length Indicator | 1 601 +-------------------------+ 602 | Version/Protocol ID | 1 603 | Extension | 604 +-------------------------+ 605 | ID Length | 1 606 +-------------------------+ 607 |R|R|R| PDU Type | 1 608 +-------------------------+ 609 | Version | 1 610 +-------------------------+ 611 | Reserved | 1 612 +-------------------------+ 613 | Maximum Area Address | 1 614 +-------------------------+ 615 | PDU Length | 2 616 +-------------------------+ 617 | Remaining Lifetime | 2 618 +-------------------------+ 619 | LSP ID | ID Length + 2 620 +-------------------------+ 621 | Sequence Number | 4 622 +-------------------------+ 623 | Checksum | 2 624 +-------------------------+ 625 |P|ATT|LSPDBOL|IS Type | 1 626 +-------------------------+ 627 : Variable Length Fields : Variable 628 +-------------------------+ 630 Intradomain Routeing Protocol Discriminator - 0x83 (as defined in 631 [ISIS]) 633 Length Indicator - Length of the Fixed Header in octets 635 Version/Protocol ID Extension - 1 637 ID Length - As defined in [ISIS] 639 PDU Type (bits 1 through 5) - 18 641 Version - 1 643 Reserved - transmitted as zero, ignored on receipt 645 Maximum Area Address - same as the primary egress PE 647 PDU Length - Entire Length of this PDU, in octets, including the 648 header. 650 Remaining Lifetime - Number of seconds before this LSP is considered 651 expired. (Set to 0x384 by default.) 653 LSP ID - the system ID of the source of the LSP. It is structured as 654 follows: 656 +-------------------------+ 657 | Source ID | 6 658 +-------------------------+ 659 | Pseudonode ID | 1 660 +-------------------------+ 661 | LSP Number | 1 662 +-------------------------+ 663 Source ID - SystemID of the vNH 665 Pseudonode ID - Transmitted as zero 667 LSP Number - Fragment number 669 Sequence Number - sequence number of this LSP (as defined in [ISIS]) 671 Checksum - As defined and computed in [ISIS] 673 P - Bit 8 - 0 675 ATT - Bit 7-4 - 0 677 LSDBOL - Bit 3 - 1 679 IS Type - Bit 1 and 2 - bit 1 set, indicating the vNH is a Level 1 680 Intermediate System 682 In the Variable Length Field, each link outgoing from the vNH to an 683 egress PE is depicted by a Type #22 Extended Intermediate System 684 Neighbors TLV [RFC5305]. The egress PE is identified by the 6 octets 685 SystemID plus one octet of all-zero pseudonode number. The 3 octets 686 metric is set as that in Section 3. None sub-TLVs is used by this 687 version, therefore the value of the one octet length of sub-TLVs is 688 0. The Type #22 TLV requires 11 octets. 690 The Type #22 TLV is also included in the LSP of each egress PE to 691 depict the incoming link of the vNH. Only the 6 octets SystemID is 692 replaced with the SystemID of the vNH. 694 Author's Addresses 696 Mingui Zhang 697 Huawei Technologies 698 No.156 Beiqing Rd. Haidian District, 699 Beijing 100095 P.R. China 701 Email: zhangmingui@huawei.com 703 Peng Zhou 704 Huawei Technologies 705 No.156 Beiqing Rd. Haidian District, 706 Beijing 100095 P.R. China 708 Email: Jewpon.zhou@huawei.com 710 Russ White 711 Verisign 712 12061 Bluemont Way 713 Reston, VA 20190 714 USA 716 Email: russw@riw.us