idnits 2.17.1 draft-ietf-ccamp-gmpls-addressing-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1062. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1052. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2007) is 6158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC3630, mentioned in 'RFC3811', was also mentioned in 'RFC3630'. -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) -- Obsolete informational reference (is this intentional?): RFC 4205 (Obsoleted by RFC 5307) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Shiomoto 2 Internet Draft NTT 3 R. Papneja 4 Intended Status: Informational Isocore 5 Expires: December 2007 R. Rabbat 6 Google 7 June 2007 9 Use of Addresses in Generalized Multi-Protocol Label Switching 10 (GMPLS) Networks 12 draft-ietf-ccamp-gmpls-addressing-08.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document clarifies the use of addresses in Generalized 41 Multi-Protocol Label Switching (GMPLS) networks. The aim is to 42 facilitate interworking of GMPLS-capable Label Switching Routers 43 (LSRs). The document is based on experience gained in implementation, 44 interoperability testing, and deployment. 46 The document describes how to interpret address and identifier fields 47 within GMPLS protocols, and how to choose which addresses to set in 48 those fields for specific control plane usage models. It also 49 discusses how to handle IPv6 sources and destinations in the MPLS and 50 GMPLS Traffic Engineering (TE) Management Information Base (MIB) 51 modules. 53 This document does not define new procedures or processes. Whenever 54 this document makes requirements statements or recommendations, these 55 are taken from normative text in the referenced RFCs. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Terminology....................................................3 61 3. Support of Numbered and Unnumbered Links.......................5 62 4. Numbered Addressing............................................6 63 4.1. Numbered Addresses in IGPs................................6 64 4.1.1. Router Address and TE Router ID......................6 65 4.1.2. Link ID and Remote Router ID.........................6 66 4.1.3. Local Interface IP Address...........................6 67 4.1.4. Remote Interface IP Address..........................7 68 4.2. Numbered Addresses in RSVP-TE.............................7 69 4.2.1. IP Tunnel End Point Address in Session Object........7 70 4.2.2. IP Tunnel Sender Address in Sender Template Object...7 71 4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces........8 72 4.2.4. Explicit Route Object (ERO)..........................8 73 4.2.5. Record Route Object (RRO)............................9 74 4.2.6. IP Packet Source Address.............................9 75 4.2.7. IP Packet Destination Address........................9 76 5. Unnumbered Addressing.........................................10 77 5.1. Unnumbered Addresses in IGPs.............................10 78 5.1.1. Link Local/Remote Identifiers in OSPF-TE............10 79 5.1.2. Link Local/Remote Identifiers in IS-IS-TE...........10 80 5.2. Unnumbered Addresses in RSVP-TE..........................10 81 5.2.1. Sender and End Point Addresses......................11 82 5.2.2. IF_ID RSVP_HOP Object for Unnumbered Interfaces.....11 83 5.2.3. Explicit Route Object (ERO).........................11 84 5.2.4. Record Route Object (RRO)...........................11 85 5.2.5. LSP_Tunnel Interface ID Object......................11 86 5.2.6. IP Packet Addresses.................................11 87 6. RSVP-TE Message Content.......................................11 88 6.1. ERO and RRO Addresses....................................12 89 6.1.1. Strict Subobject in ERO.............................12 90 6.1.2. Loose Subobject in ERO..............................13 91 6.1.3. RRO.................................................13 92 6.1.4. Label Record subobject in RRO.......................14 93 6.2. Component Link Identification............................15 94 6.3. Forwarding Destination of Path Messages with ERO.........15 95 7. Topics Related to the GMPLS Control Plane.....................16 96 7.1. Control Channel Separation...............................16 97 7.1.1. Native and Tunneled Control Plane...................16 98 7.2. Separation of Control and Data Plane Traffic.............16 99 8. Addresses in the MPLS and GMPLS TE MIB Modules................17 100 8.1. Handling IPv6 Source and Destination Addresses...........17 101 8.1.1. Identifying LSRs....................................17 102 8.1.2. Configuring GMPLS Tunnels...........................17 104 8.2. Managing and Monitoring Tunnel Table Entries.............18 105 9. Security Considerations.......................................19 106 10. IANA Considerations..........................................19 107 11. Acknowledgments..............................................19 108 12. Authors' Addresses...........................................19 109 13. References...................................................20 110 13.1. Normative References....................................20 111 13.2. Informative References..................................21 113 1. Introduction 115 This informational document clarifies the use of addresses in 116 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] 117 networks. The aim is to facilitate interworking of GMPLS-capable 118 Label Switching Routers (LSRs). The document is based on experience 119 gained in implementation, interoperability testing, and deployment. 121 The document describes how to interpret address and identifier fields 122 within GMPLS protocols (RSVP-TE [RFC3473], GMPLS OSPF [RFC4203], 123 and GMPLS ISIS [RFC4205]), and how to choose which addresses to 124 set in those fields for specific control plane usage models. 126 This document does not define new procedures or processes and the 127 protocol specifications listed above should be treated as definitive. 128 Furthermore, where this document makes requirements statements or 129 recommendations, these are taken from normative text in the 130 referenced RFCs. Nothing in this document should be considered 131 normative. 133 This document also discusses how to handle IPv6 sources and 134 destinations in the MPLS and GMPLS Traffic Engineering (TE) 135 Management Information Base (MIB) modules [RFC3812], [RFC4802]. 137 2. Terminology 139 As described in [RFC3945], the components of a GMPLS network may 140 be separated into a data plane and a control plane. The control 141 plane may be further split into signaling components and routing 142 components. 144 A data plane switch or router is called a data plane entity. It is a 145 node on the daa plane topology graph. A data plane resource is a 146 facility available in the data plane, such as a data plane entity 147 (node), data link (edge), or data label (such as a lambda). 149 In the control plane, there are protocol speakers that are software 150 implementations that communicate using signaling or routing 151 protocols. These are control plane entities, and may be physically 152 located separately from the data plane entities that they control. 153 Further, there may be separate routing entities and signaling 154 entities. 156 GMPLS supports a control plane entity that is responsible for one or 157 more data plane entities, and supports the separation of signaling 158 and routing control plane entities. For the purposes of this 159 document, it is assumed that there is a one-to-one correspondence 160 between control plane and data plane entities. That is, each data 161 plane switch has a unique control plane entity responsible for 162 participating in the GMPLS signaling and routing protocols, and that 163 each such control plane presence is responsible for a single data 164 plane switch. Future documents may focus on more sophisticated 165 deployment scenarios. 167 The combination of control plane and data plane entities is referred 168 to as a Label Switching Router (LSR). 170 Note that the term 'Router ID' is used in two contexts within GMPLS. 171 It may refer to an identifier of a participant in a routing protocol, 172 or it may be an identifier for an LSR that participates in TE 173 routing. These could be considered as the control plane and data 174 plane contexts. 176 In this document, the contexts are distinguished by the following 177 definitions. 179 o Loopback address: A loopback address is a stable IP address of the 180 advertising router that is always reachable if there is any IP 181 connectivity to it [RFC3477], [RFC3630]. Thus, for example, an 182 IPv4 127/24 address is excluded from this definition. 184 o TE Router ID: A stable IP address of an LSR that is always 185 reachable in the control plane if there is any IP connectivity to 186 the LSR, e.g., a loopback address. The most important requirement 187 is that the address does not become unusable if an interface on 188 the LSR is down [RFC3477], [RFC3630]. 190 o Router ID: The OSPF protocol version 2 [RFC2328] defines the 191 Router ID to be a 32-bit network unique number assigned to each 192 router running OSPF. IS-IS [RFC1195] includes a similar concept in 193 the System ID. This document describes both concepts as the 194 "Router ID" of the router running the routing protocol. The 195 Router ID is not required to be a reachable IP address, although 196 an operator may set it to a reachable IP address on the same 197 system. 199 o TE link: "A TE link is a representation in the IS-IS/OSPF Link 200 State advertisements and in the link state database of certain 201 physical resources, and their properties, between two GMPLS 202 nodes." [RFC3945] 204 o Data plane node: A vertex on the TE graph. It is a data plane 205 switch or router. Data plane nodes are connected by TE links 206 which are constructed from physical data links. A data plane node 207 is controlled through some combination of management and control 208 plane actions. A data plane node may be under full or partial 209 control of a control plane node. 211 o Control plane node: A GMPLS protocol speaker. It may be part of a 212 data plane switch or may be a separate computer. Control plane 213 nodes are connected by control channels which are logical 214 connectionless or connection-oriented paths in the control plane. 215 A control plane node is responsible for controlling zero, one or 216 more data plane nodes. 218 o Interface ID: The Interface ID is defined in [RFC3477] and in 219 section 9.1 of [RFC3471]. 221 o Data Plane Address: This document refers to a data plane address 222 in the context of GMPLS. It does not refer to addresses such as 223 E.164 SAPI in SDH. 225 o Control Plane Address: An address used to identify a control plane 226 resource including, and restricted to, control plane nodes and 227 control channels. 229 o IP TTL: The IPv4 TTL field or the IPv6 Hop Limit field, whichever 230 is applicable. 232 o TED: Traffic Engineering Database. 234 o LSR: Label Switching Router. 236 o FA: Forwarding Adjacency. 238 3. Support of Numbered and Unnumbered Links 240 The links in the control and data planes may be numbered or 241 unnumbered [RFC3945]. That is, their end-points may be assigned IP 242 addresses, or may be assigned link IDs specific to the control plane 243 or data plane entity at the end of the link. Implementations may 244 decide to support numbered and/or unnumbered addressing. 246 The argument for numbered addressing is that it simplifies 247 troubleshooting. The argument for unnumbered addressing is to save on 248 IP address resources. 250 Even if an LSR does not support its own links being configured as one 251 of numbered or unnumbered, failure to support other LSRs in their 252 choice to use numbered or unnumbered addressing may lead to a lack of 253 interoperability. Thus, a node should be able to accept and process 254 link advertisements containing both numbered and unnumbered 255 addresses. 257 Numbered and unnumbered addressing is described in Sections 4 and 5 258 of this document respectively. 260 4. Numbered Addressing 262 When numbered addressing is used, addresses are assigned to each node 263 and link in both the control and data planes of the GMPLS network. 265 A numbered link is identified by a network unique identifier (e.g., 266 an IP address). 268 4.1. Numbered Addresses in IGPs 270 In this section we discuss numbered addressing using two Interior 271 Gateway Protocols (IGPs) that have extensions defined for GMPLS: 272 OSPF-TE and IS-IS-TE. The routing enhancements for GMPLS are defined 273 in [RFC3630], [RFC3784], [RFC4202], [RFC4203], and [RFC4205]. 275 4.1.1. Router Address and TE Router ID 277 The IGPs define a field called the "Router Address". It is used to 278 advertise the TE Router ID. 280 The Router Address is advertised in OSPF-TE using the Router Address 281 TLV structure of the TE LSA [RFC3630]. 283 In IS-IS-TE, this is referred to as the Traffic Engineering router 284 ID, and is carried in the advertised Traffic Engineering router ID 285 TLV [RFC3784]. 287 4.1.2. Link ID and Remote Router ID 289 In OSPF-TE [RFC3630] the Router ID of the remote end of a TE link is 290 carried in the Link ID sub-TLV. This applies for point-to-point TE 291 links only; multi-access links are left for further study. 293 In IS-IS-TE [RFC3784] the Extended IS Reachability TLV is used to 294 carry the System ID. This corresponds to the Router ID as described 295 in Section 2. 297 4.1.3. Local Interface IP Address 299 The Local Interface IP Address is advertised in: 301 o the Local Interface IP Address sub-TLV in OSPF-TE [RFC3630] 303 o the IPv4 Interface Address sub-TLV in IS-IS-TE [RFC3784]. 305 This is the ID of the local end of the numbered TE link. It must be 306 a network unique number (since this section is devoted to numbered 307 addressing), but it does not need to be a routable address in the 308 control plane. 310 4.1.4. Remote Interface IP Address 312 The Remote Interface IP Address is advertised in: 314 o the Remote Interface IP Address sub-TLV in OSPF-TE [RFC3630] 316 o the IPv4 Neighbor Address sub-TLV in IS-IS-TE [RFC3784]. 318 This is the ID of the remote end of the numbered TE link. It must be 319 a network unique number (since this section is devoted to numbered 320 addressing), but it does not need to be a routable address in the 321 control plane 323 4.2. Numbered Addresses in RSVP-TE 325 The following subsections describe the use of addresses in the GMPLS 326 signaling protocol [RFC3209], [RFC3473]. 328 4.2.1. IP Tunnel End Point Address in Session Object 330 The IP tunnel end point address of the Session Object [RFC3209] is 331 either an IPv4 or IPv6 address. 333 The Session Object is invariant for all messages relating to the same 334 label Switched Path (LSP). The initiator of a Path message sets the 335 IP tunnel endpoint address in the Session Object to one of: 337 o The TE Router ID of the egress since the TE Router ID is routable 338 uniquely identifies the egress node. 340 o The destination data plane address to precisely identify the 341 interface that should be used for the final hop of the LSP. That 342 is, the Remote Interface IP Address of the final TE link, if the 343 ingress knows that address. 345 The IP tunnel endpoint address in the Session Object is not required 346 to be routable in the control plane, but should be present in the 347 TED. 349 4.2.2. IP Tunnel Sender Address in Sender Template Object 351 The IP tunnel sender address of the Sender Template Object [RFC3209] 352 is either an IPv4 or IPv6 address. 354 When an LSP is being set up to support an IPv4 numbered FA, [RFC4206] 355 recommends that the IP tunnel sender address be set to the head-end 356 address of the TE link that is to be created so that the tail-end 357 address can be inferred as the /31 partner address. 359 When an LSP is being set up that will not be used to form an FA, the 360 IP tunnel sender address in the Sender Template Object may be set to 361 one of: 363 o The TE Router ID of the ingress LSR since the TE Router ID is a 364 unique, routable ID per node. 366 o The sender data plane address (i.e., the Local Interface IP 367 Address). 369 4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces 371 There are two addresses used in the IF_ID RSVP_HOP object. 373 1. The IPv4/IPv6 Next/Previous Hop Address [RFC3473] 375 When used in a Path or Resv messages, this address specifies the 376 IP reachable address of the control plane interface used to send 377 the messages, or the TE Router ID of the node that sends the 378 message. That is, it is a routable control plane address of the 379 sender of the message and can be used to sned return messages. 380 Note that because of data plane / control plane separation (see 381 Section 7.1) and data plane robustness in the face of control 382 plane faults, it may be advisable to use the TE Router ID since it 383 is a more stable address. 385 2. The IPv4/IPv6 address in the Value Field of the Interface_ID TLV 386 [RFC3471] 388 This address identifies the data channel associated with the 389 signaling message. In all cases the data channel is indicated by 390 the use of the data plane local interface address at the upstream 391 LSR, that is, at the sender of the Path message. 393 See Section 6.2 for a description of these fields when bundled links 394 are used. 396 4.2.4. Explicit Route Object (ERO) 398 The IPv4/IPv6 address in the ERO provides a data-plane identifier of 399 an abstract node, TE node, or TE link to be part of the signaled LSP. 401 See Section 6 for a description of the use of addresses in the ERO. 403 4.2.5. Record Route Object (RRO) 405 The IPv4/IPv6 address in the RRO provides a data-plane identifier of 406 either a TE node or a TE link that is part of an LSP that has been 407 established or is being established. 409 See Section 6 for a description of the use of addresses in the RRO. 411 4.2.6. IP Packet Source Address 413 GMPLS signaling messages are encapsulated in IP. The IP packet source 414 address is either an IPv4 or IPv6 address and must be a reachable 415 control plane address of the node sending the TE message. In order to 416 provide control plane robustness, a stable IPv4 or IPv6 control plane 417 address (for example, the TE Router ID) can be used. 419 Some implementations may use the IP source address of a received IP 420 packet containing a Path message as the destination IP address of a 421 packet containing the corresponding Resv message (see Section 4.2.7). 422 Using a stable IPv4 or IPv6 address in the IP packet containing the 423 Path message supports this situation robustly when one of control 424 plane interfaces is down. 426 4.2.7. IP Packet Destination Address 428 The IP packet destination address for an IP packet carrying a GMPLS 429 signaling message is either an IPv4 or IPv6 address, and must be 430 reachable in the control plane if the message is to be delivered. 431 It must be an address of the intended next-hop recipient of the 432 message. That is, unlike RSVP, the IP packet is not addressed to 433 the ultimate destination (the egress). 435 For a Path message, a stable IPv4 or IPv6 address of the next hop 436 node may be used. This may be the TE Router ID of the next hop node. 437 A suitable address may be determined by examining the TE 438 advertisements for the TE link that will form the next hop data link. 440 A Resv message is sent to the previous hop node. The IPv4 or IPv6 441 destination of an IP packet carrying a Resv message may be any of the 442 following: 444 o The IPv4 or IPv6 source address of the received IP packet 445 containing the Path message. 447 o A stable IPv4 or IPv6 address of the previous node found by 448 examining the TE advertisements for the upstream data plane 449 interface. 451 o The value in the received in the Next/Previous Hop Address field 452 of the RSVP_HOP (PHOP) Objec [RFC2205]. 454 5. Unnumbered Addressing 456 An unnumbered address is the combination of a network unique node 457 identifier and a node unique interface identifier. 459 An unnumbered link is identified by the combination of the TE Router 460 ID that is a reachable address in the control plane and a node-unique 461 Interface ID [RFC3477]. 463 5.1. Unnumbered Addresses in IGPs 465 In this section we consider unnumbered address advertisement using 466 OSPF-TE and IS-IS-TE. 468 5.1.1. Link Local/Remote Identifiers in OSPF-TE 470 Link Local and Link Remote Identifiers are carried in OSPF using a 471 single sub-TLV of the Link TLV [RFC4203]. They advertise the IDs of 472 an unnumbered TE link's local and remote ends respectively. Link 473 Local/Remote Identifiers are numbers unique within the scopes of the 474 advertising LSR and the LSR managing the remote end of the link 475 respectively [RFC3477]. 477 Note that these numbers are not network unique and therefore cannot 478 be used as TE link end identifiers on their own. An unnumbered TE 479 link end network-wide identifier is comprised of two elements as 480 defined in [RFC3477]: 482 - A TE Router ID that is associated with the link local end 484 - The link local identifier. 486 5.1.2. Link Local/Remote Identifiers in IS-IS-TE 488 The Link Local and Link Remote Identifiers are carried in IS-IS using 489 a single sub-TLV of the Extended IS Reachability TLV. Link 490 identifiers are exchanged in the Extended Local Circuit ID field of 491 the "Point-to-Point Three-Way Adjacency" IS-IS Option type [RFC4205]. 493 The same discussion of unique identification applies here as in 494 Section 5.1.1. 496 5.2. Unnumbered Addresses in RSVP-TE 498 We consider in this section the interface ID fields of objects used 499 in RSVP-TE in the case of unnumbered addressing. 501 5.2.1. Sender and End Point Addresses 503 The IP Tunnel End Point Address in the RSVP Session Object and the IP 504 Tunnel Sender Address in the RSVP Sender Template Object cannot use 505 unnumbered addresses [RFC3209], [RFC3473]. 507 5.2.2. IF_ID RSVP_HOP Object for Unnumbered Interfaces 509 The interface ID field in the IF_INDEX TLV specifies the interface of 510 the data channel for an unnumbered interface. 512 In both Path and Resv messages, the value of the interface ID in the 513 IF_INDEX TLV specifies the local interface ID of the associated data 514 channel at the upstream node (the node sending the Path message and 515 receiving the Resv message). 517 See Section 6.2 for a description of the use bundled links. 519 5.2.3. Explicit Route Object (ERO) 521 The ERO may use an unnumbered identifier of a TE link to be part of 522 the signaled LSP. 524 See Section 6 for a description of the use of addresses in the ERO. 526 5.2.4. Record Route Object (RRO) 528 The RRO records the data-plane identifiers of TE nodes and TE links 529 that are part of an LSP that has been established or is being 530 established. TE links may be identified using unnumbered addressing. 532 See Section 6 for a description of the use of addresses in the RRO. 534 5.2.5. LSP_Tunnel Interface ID Object 536 The LSP_TUNNEL_INTERFACE_ID Object includes the LSR's Router ID and 537 Interface ID as described in [RFC3477] to specify an unnumbered 538 Forward Adjacency Interface ID. The Router ID of the GMPLS-capable 539 LSR must be set to the TE Router ID. 541 5.2.6. IP Packet Addresses 543 IP packets can only be addressed to numbered addresses. 545 6. RSVP-TE Message Content 547 This section examines the use of addresses in RSVP EROs and RROs, the 548 identification of component links, and forwarding addresses for RSVP 549 mssages. 551 6.1. ERO and RRO Addresses 553 EROs may contain strict or loose hop subobjects. These are discussed 554 separately below. A separate section describes the use of addresses 555 in the RRO. 557 Implementations making limited assumptions about the content of an 558 ERO or RRO when processing a received RSVP message may cause or 559 experience interoperability issues. Therefore, implementations that 560 want to ensure full interoperability need to support the receipt for 561 processing of all ERO and RRO options applicable to their hardware 562 capabilities. 564 Note that the phrase "receipt for processing" is intended to indicate 565 that an LSR is not expected to look ahead in an ERO or process any 566 subobjects that do not refer to the LSR itself or to the next hop in 567 the ERO. An LSR is not generally expected to process an RRO except by 568 adding its own information. 570 Note also that implementations do not need to support the ERO options 571 containing Component Link IDs if they do not support link bundling 572 [RFC4201]. 574 ERO processing at region boundaries is described in [RFC4206]. 576 6.1.1. Strict Subobject in ERO 578 Depending on the level of control required, a subobject in the 579 ERO includes an address that may specify an abstract node (i.e., a 580 group of nodes), a simple abstract node (i.e., a specific node), or a 581 specific interface of a TE link in the data plane [RFC3209]. 583 A hop may be flagged as strict (meaning that the LSP must go direct 584 to the identified next hop without any intervening nodes), or loose. 586 If a hop is strict, the ERO may contain any of the following. 588 1. Address prefix or AS number specifying a group of nodes. 590 2. TE Router ID identifying a specific node. 592 3. Link ID identifying an incoming TE link. 594 4. Link ID identifying an outgoing TE link, optionally followed by a 595 Component Interface ID and/or one or two Labels. 597 5. Link ID identifying an incoming TE link followed by a Link ID 598 identifying an outgoing TE link, optionally followed by a 599 Component Interface ID and/or one or two Labels. 601 6. TE Router ID identifying a specific node followed by a Link ID 602 identifying an outgoing TE link, optionally followed by a 603 Component Interface ID and/or one or two Labels. 605 7. Link ID identifying an incoming TE link followed by a TE Router ID 606 identifying a specific node followed by a Link ID identifying an 607 outgoing TE link, optionally followed by Component Interface ID 608 and/or one or two Labels. 610 The label value that identifies a single unidirectional resource 611 between two nodes may be different from the perspective of upstream 612 and downstream nodes. This is typically the case in fiber switching 613 because the label value is a number indicating the port/fiber. It may 614 also be the case for lambda switching, because the label value is an 615 index for the lambda in the hardware and may not be a globally 616 defined value such as the wavelength in nanometres. 618 The value of a label in any RSVP-TE object indicates the value from 619 the perspective of the sender of the object/TLV [RFC3471]. Therefore, 620 any label in an ERO is given using the upstream node's identification 621 of the resource. 623 6.1.2. Loose Subobject in ERO 625 There are two differences between Loose and Strict subobjects. 627 o A subobject marked as a loose hop in an ERO must not be followed 628 by a subobject indicating a label value [RFC3473]. 630 o A subobject marked as a loose hop in an ERO should never include 631 an identifier (i.e., address or ID) of outgoing interface. 633 There is no way to specify in an ERO whether a subobject identifies 634 an incoming or outgoing TE link. Path computation must be performed 635 by an LSR when it encounters a loose hop in order to resolve the LSP 636 route to the identified next hop. If an interface is specified as a 637 loose hop and is treated as an incoming interface, the path 638 computation will select a path that enters an LSR through that 639 interface. If the interface was intended to be used as an outgoing 640 interface, the computed path may be unsatisfactory and the explicit 641 route in the ERO may be impossible to resolve. Thus a loose hop that 642 identifies an interface should always identify the incoming TE link 643 in the data plane. 645 6.1.3. RRO 647 The RRO is used on Path and Resv messages to record the path of an 648 LSP. Each LSR adds subobjects to the RRO to record information. The 649 information added to an RRO by a node should be the same in the Path 650 and the Resv message although there may be some information that is 651 not available during LSP setup. 653 One use of the RRO is to allow the operator to view the path of the 654 LSP. At any transit node it should be possible to construct the path 655 of the LSP by joining together the RRO from the Path and the Resv 656 messages. 658 It is also important that a whole RRO on a Resv message received at 659 an ingress LSR could be used as an ERO on a subsequent Path message 660 to completely recreate the LSP. 662 Therefore, when a node adds one or more subobjects to an RRO, any 663 of the following options is valid. 665 1. TE Router ID identifying the LSR. 667 2. Link ID identifying the incoming (upstream) TE link. 669 3. Link ID identifying the outgoing (downstream) TE link, optionally 670 followed by a Component Interface ID and/or one or two Labels. 672 4. Link ID identifying the incoming (upstream) TE link followed by a 673 Link ID identifying the outgoing (downstream) TE link, optionally 674 followed by a Component Interface ID and/or one or two Labels. 676 5. TE Router ID identifying the LSR followed by a Link ID identifying 677 the outgoing (downstream) TE link, optionally followed by a 678 Component Interface ID and/or one or two Labels. 680 6. Link ID identifying the incoming (upstream) TE link followed by 681 the TE Router ID identifying the LSR followed by a Link ID 682 identifying the outgoing (downstream) TE link, optionally followed 683 by a Component Interface ID and/or one or two Labels. 685 An implementation may choose any of these options and must be 686 prepared to receive an RRO that contains any of these options. 688 6.1.4. Label Record subobject in RRO 690 RRO Label recording is requested by an ingress node setting the Label 691 Recording flag is set in the SESSION_ATTRIBUTE object and including 692 an RRO is included in the Path message as described in [RFC3209]. 693 Under these circumstances, each LSR along the LSP should include 694 label information in the RRO in the Path message if it is available. 696 As described in [RFC3209], the processing for a Resv message "mirrors 697 that of the Path" and "The only difference is that the RRO in a Resv 698 message records the path information in the reverse direction." This 699 means that hops are added to the RRO in the reverse order, but the 700 information added at each LSR is in the same order (see Sections 701 6.1.1, 6.1.2, and 6.1.3). Thus, when label recording is requested, 702 labels are included in the RROs in both the Path and Resv messages. 704 6.2. Component Link Identification 706 When a bundled link [RFC4201] is used to provide a data channel, a 707 component link identifier is specified in the Interface 708 Identification TLV in the IF_ID RSVP_HOP Object in order to indicate 709 which data channel from within the bundle is to be used. The 710 Interface Identification TLV is IF_INDEX TLV (Type 3) in the case 711 of an unnumbered component link and IPv4 TLV (Type 1) or IPv6 TLV 712 (Type 2) in the case of a numbered component link. 714 The component link for the upstream data channel may differ from that 715 for the downstream data channel in the case of a bi-directional LSP. 716 In this case, the Interface Identification TLV specifying a 717 downstream interface is followed by another Interface Identification 718 TLV specifying an upstream interface. 720 Note that identifiers in TLVs for upstream and downstream data 721 channels in both Path and Resv messages are specified from the 722 viewpoint of the upstream node (the node sending the Path message and 723 receiving the Resv message), using identifiers belonging to the node. 725 An LSR constructing an ERO may include a Link ID that identifies a 726 bundled link. If the LSR knows the identities of the component links 727 and wishes to exert control, it may also include component link 728 identifiers in the ERO. Otherwise, the component link identifiers are 729 not included in the ERO. 731 When a bundled link is in use, the RRO may include the Link ID that 732 identifies the link bundle. Additionally, the RRO may include a 733 component link identifier. 735 6.3. Forwarding Destination of Path Messages with ERO 737 The final destination of the Path message is the Egress node that is 738 specified by the tunnel end point address in the Session object. 740 The Egress node must not forward the corresponding Path message 741 downstream, even if the ERO includes the outgoing interface ID of the 742 Egress node for Egress control [RFC4003]. 744 7. Topics Related to the GMPLS Control Plane 746 7.1. Control Channel Separation 748 In GMPLS, a control channel can be separated from the data channel 749 and there is not necessarily a one-to-one association of a control 750 channel to a data channel. Two nodes that are adjacent in the data 751 plane may have multiple IP hops between them in the control plane. 753 There are two broad types of separated control planes: native and 754 tunneled. These differ primarily in the nature of encapsulation used 755 for signaling messages, which also results in slightly different 756 address handling with respect to the control plane address. 758 7.1.1. Native and Tunneled Control Plane 760 A native control plane uses IP forwarding to deliver RSVP-TE messages 761 between protocol speakers. The message is not further encapsulated. 763 IP forwarding applies normal rules to the IP header. Note that an IP 764 hop must not decrement the TTL of the received RSVP-TE message. 766 For the case where two adjacent nodes have multiple IP hops between 767 them in the control plane, then as stated in section 9 of [RFC3945], 768 implementations should use the mechanisms of section 6.1.1 of 769 [RFC4206] whether or not they use LSP Hierarchy. Note that section 770 6.1.1 of [RFC4206] applies to an "FA-LSP" as stated in that section, 771 but also to a "TE link" for the case where a normal TE link is used. 773 With a tunneled control plane, the RSVP-TE message is packaged in an 774 IP packet that is inserted into a tunnel such that the IP packet will 775 traverse exactly one IP hop. Various tunneling techniques can be used 776 including, but not limited to IP-in-IP, GRE, and IP in MPLS. 778 Where the tunneling mechanism includes a TTL it should be treated as 779 for any network message sent on that network. Implementations 780 receiving RSVP-TE messages on the tunnel interface must not compare 781 the RSVP-TE TTL to any other TTL (whether the IP TTL, or the tunnel 782 TTL). 784 It has been observed that some implementations do not support the 785 tunneled control plane features and it is suggested that to enable 786 interoperability, all implementation should support at least a native 787 control plane. 789 7.2. Separation of Control and Data Plane Traffic 791 Data traffic must not be transmitted through the control plane. This 792 is crucial when attempting PSC (Packet-Switching Capable) GMPLS with 793 separated control and data channels. 795 8. Addresses in the MPLS and GMPLS TE MIB Modules 797 This section describes a method of defining or monitoring an LSP 798 tunnel using the MPLS-TE-STD-MIB module [RFC3812] and 799 GMPLS-TE-STD-MIB module [RFC4802] where the ingress and/or egress 800 routers are identified using 128-bit IPv6 addresses. That is, where 801 the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the 802 mplsTunnelTable [RFC3812] cannot be used to carry the tunnel end 803 point address and Extended Tunnel Id fields from the signaled Session 804 Object because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is 805 in use. 807 The normative text for MIB objects for control and monitoring MPLS 808 and GMPLS systems is found in the RFCs referenced above. This section 809 makes no changes to those objects, but describes how they may be used 810 to provide the necessary function. 812 8.1. Handling IPv6 Source and Destination Addresses 814 8.1.1. Identifying LSRs 816 For this feature to be used, all LSRs in the network must advertise a 817 32-bit value that can be used to identify the LSR. In this document, 818 this is referred to as the 32-bit LSR ID. The 32-bit LSR ID is the 819 OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. 820 Note that these are different from TE router ID (See Section 2). 822 8.1.2. Configuring GMPLS Tunnels 824 When setting up RSVP TE tunnels, it is common practice to copy the 825 values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields 826 in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel 827 ID and IPv4 tunnel end point address fields, respectively, in the 828 RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209]. 830 This approach cannot be used when the ingress and egress routers are 831 identified by 128-bit IPv6 addresses as the mplsTunnelIngressLSRId 832 and mplsTunnelEgressLSRId fields are defined to be 32-bit values 833 [RFC3811] and [RFC3812]. 835 Instead, the IPv6 addresses should be configured in the mplsHopTable 836 as the first and last hops of the mplsTunnelHopTable entries defining 837 the explicit route for the tunnel. Note that this implies that a 838 tunnel with IPv6 source and destination addresses must have an 839 explicit route configured, although it should be noted that the 840 configuration of an explicit route in this way does not imply that an 841 explicit route will be signaled. 843 In more detail, the tunnel is configured at the ingress router as 844 follows. See [RFC3812] for definitions of MIB table objects and for 845 default (that is, "normal") behavior. 847 The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. 849 The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields should be 850 set to 32-bit LSR IDs for ingress and egress LSR respectively. 852 The mplsTunnelHopTableIndex must be set to a non-zero value. That 853 is, an explicit route must be specified. 855 The first hop of the explicit route must have mplsTunnelHopAddrType 856 field set to ipv6(2) and should have the mplsTunnelHopIpAddr field 857 set to a global scope IPv6 address of the ingress router that is 858 reachable in the control plane. 860 The last hop of the explicit route must have mplsTunnelHopAddrType 861 field set to ipv6(2) and should have the mplsTunnelHopIpAddr field 862 set to a global scope IPv6 address of the egress router that is 863 reachable in the control plane. 865 The ingress router should set the signaled values of the Extended 867 Tunnel ID and IPv6 tunnel end point address fields, respectively, of 868 the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [RFC3209] from the 869 mplsTunnelHopIpAddr object of the first and last hops in the 870 configured explicit route. 872 8.2. Managing and Monitoring Tunnel Table Entries 874 As well as their use for configuring LSPs as described in Section 875 8.1, the TE MIB modules (MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB) may be 876 used for managing and monitoring MPLS and GMPLS TE LSPs respectively. 877 This function is particularly important at egress and transit LSRs. 879 For a tunnel with IPv6 source and destination addresses, an LSR 880 implementation should return values in the mplsTunnelTable as follows 881 (where "normal" behavior is the default taken from [RFC3812]). 883 The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. 885 The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to 886 32-bit LSR IDs. That is, each transit and egress router maps from 887 the IPv6 address in the Extended Tunnel ID field to the 32-bit LSR ID 888 of the ingress LSR. Each transit router also maps from the IPv6 889 address in the IPv6 tunnel end point address field to the 32-bit LSR 890 ID of the egress LSR. 892 9. Security Considerations 894 In the interoperability testing we conducted, the major issue we 895 found was the use of control channels for forwarding data. This was 896 due to the setting of both control and data plane addresses to the 897 same value in PSC (Packet-Switching Capable) equipment. This 898 occurred when attempting to test PSC GMPLS with separated control and 899 data channels. What resulted instead were parallel interfaces with 900 the same addresses. This could be avoided simply by keeping the 901 addresses for the control and data plane separate. 903 10. IANA Considerations 905 This document defines no new code points and requires no action from 906 IANA. 908 11. Acknowledgments 910 The following people made textual contributions to this document: 912 Alan Davey, Yumiko Kawashima, Kaori Shimizu, Thomas D. Nadeau, 913 Ashok Narayanan, Eiji Oki, Lyndon Ong, Vijay Pandian, 914 Hari Rakotoranto, and Adrian Farrel. 916 The authors would like to thank Adrian Farrel for the helpful 917 discussions and the feedback he gave on the document. In addition, 918 Jari Arkko, Arthi Ayyangar, Deborah Brungard, Diego Caviglia, Lisa 919 Dusseault, Dimitri Papadimitriou, Jonathan Sadler, Hidetsugu 920 Sugiyama, and Julien Meuric provided helpful comments and 921 suggestions. 923 Adrian Farrel edited the final revisions of this document before and 924 after working group last call. 926 12. Authors' Addresses 928 Kohei Shiomoto 929 NTT Network Service Systems Laboratories 930 3-9-11 Midori 931 Musashino, Tokyo 180-8585 932 Japan 934 Phone: +81 422 59 4402 935 Email: shiomoto.kohei@lab.ntt.co.jp 937 Richard Rabbat 938 Google Inc. 940 Email: rabbat@alum.mit.edu 941 Rajiv Papneja 942 Isocore Corporation 943 12359 Sunrise Valley Drive, Suite 100 944 Reston, Virginia 20191 945 United States of America 947 Phone: +1 703-860-9273 948 Email: rpapneja@isocore.com 950 13. References 952 13.1. Normative References 954 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 955 "Resource ReSerVation Protocol (RSVP) -- Version 1, 956 Functional Specification", RFC 2205, September 1997. 958 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 960 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 961 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 962 Tunnels", RFC 3209, December 2001. 964 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 965 (GMPLS) Signaling Functional Description", RFC 3471, 966 January 2003. 968 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 969 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 970 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 972 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 973 in Resource ReSerVation Protocol - Traffic Engineering 974 (RSVP-TE)", RFC 3477, January 2003. 976 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 977 (TE) Extensions to OSPF Version 2", RFC 3630, September 978 2003. 980 [RFC3811] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 981 (TE) Extensions to OSPF Version 2", RFC 3630, September 982 2003. 984 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 985 "Multiprotocol Label Switching (MPLS) Traffic Engineering 986 (TE) Management Information Base (MIB)", RFC 3812, 987 June 2004. 989 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 990 (GMPLS) Architecture", RFC 3945, October 2004. 992 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", 993 RFC 4003, February 2005. 995 [RFC4201] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in 996 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 998 [RFC4202] Kompella, K. and Y. Rekhter (Eds.), "Routing Extensions in 999 Support of Generalized Multi-protocol Label Switching", 1000 RFC 4202, October 2005. 1002 [RFC4203] Kompella, K. and Y. Rekhter (Eds.), "OSPF Extensions in 1003 Support of Generalized Multi-protocol Label Switching", 1004 RFC 4203, October 2005. 1006 [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 1007 Generalized MPLS TE", RFC 4206, October 2005. 1009 13.2. Informative References 1011 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1012 dual environments", RFC 1195, December 1990. 1014 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 1015 RFC 2740, December 1999. 1017 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 1018 System (IS-IS) Extensions for Traffic Engineering (TE)", 1019 RFC 3784, June 2004. 1021 [RFC4205] Kompella, K. and Y. Rekhter (Eds.), "Intermediate System to 1022 Intermediate System (IS-IS) Extensions in Support of 1023 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 1024 4205, October 2005. 1026 [RFC4802] Nadeau, T. and A. Farrel (Eds.), "Generalized Multiprotocol 1027 Label Switching (GMPLS) Traffic Engineering Management 1028 Information Base", RFC 4802, February 2007. 1030 Intellectual Property Statement 1032 The IETF takes no position regarding the validity or scope of any 1033 Intellectual Property Rights or other rights that might be claimed to 1034 pertain to the implementation or use of the technology described in 1035 this document or the extent to which any license under such rights 1036 might or might not be available; nor does it represent that it has 1037 made any independent effort to identify any such rights. Information 1038 on the procedures with respect to rights in RFC documents can be 1039 found in BCP 78 and BCP 79. 1041 Copies of IPR disclosures made to the IETF Secretariat and any 1042 assurances of licenses to be made available, or the result of an 1043 attempt made to obtain a general license or permission for the use of 1044 such proprietary rights by implementers or users of this 1045 specification can be obtained from the IETF on-line IPR repository at 1046 http://www.ietf.org/ipr. 1048 The IETF invites any interested party to bring to its attention any 1049 copyrights, patents or patent applications, or other proprietary 1050 rights that may cover technology that may be required to implement 1051 this standard. Please address the information to the IETF at 1052 ietf-ipr@ietf.org. 1054 Disclaimer of Validity 1056 This document and the information contained herein are provided on an 1057 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1058 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1059 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1060 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1061 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1062 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1064 Copyright Statement 1066 Copyright (C) The IETF Trust (2007). 1068 This document is subject to the rights, licenses and restrictions 1069 contained in BCP 78, and except as set forth therein, the authors 1070 retain all their rights.