idnits 2.17.1 draft-shiomoto-ccamp-gmpls-addressing-01.txt: -(164): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(206): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(493): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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.5 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 648. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (April 2005) is 6951 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3667' is defined on line 737, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 740, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- No information found for draft-ietf-ccamp-gmpls-ospf-gmpls-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-OSPF' -- Obsolete informational reference (is this intentional?): RFC 3373 (Obsoleted by RFC 5303) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Kohei Shiomoto (NTT) 3 Internet Draft Rajiv Papneja (ISOCORE) 4 Expires: October 2005 Richard Rabbat (Fujitsu) 6 April 2005 8 Addressing and Messaging in Generalized Multi-Protocol Label 9 Switching (GMPLS) Networks 11 draft-shiomoto-ccamp-gmpls-addressing-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC3668. 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 explains and clarifies addressing and messaging in 41 Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim 42 of this document is to facilitate and ensure better interworking of 43 GMPLS-capable Label Switching Routers (LSR) based on experience 44 gained in deployments and interoperability testing and proper 45 interpretation of published RFCs. 47 The document recommends a proper approach for the interpretation and 48 choice of address and identifier fields within GMPLS protocols and 49 references specific control plane usage models. It also examines 50 some common GMPLS Resource Reservation Protocol-Traffic Engineering 51 (RSVP-TE) signaling message processing issues and recommends 52 solutions. 54 Table of Contents 56 1. Introduction...................................................3 57 2. Conventions Used in This Document..............................3 58 3. Terminology....................................................3 59 4. Numbered Addressing............................................4 60 4.1. Interior Gateway Protocols...................................5 61 4.1.1. Router Address.............................................6 62 4.1.2. Link ID sub-TLV............................................6 63 4.1.3. Local Interface IP Address.................................6 64 4.1.4. Remote Interface IP Address................................6 65 4.2. Use of Addresses in RSVP-TE..................................6 66 4.2.1. IP Tunnel End Point Address in Session Object..............6 67 4.2.2. IP Tunnel Sender Address in Sender Template Object.........7 68 4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces..............7 69 4.2.4. Explicit Route Object (ERO)................................7 70 4.2.5. Record Route Object (RRO)..................................8 71 4.3. IP Packet Destination Address................................8 72 4.4. IP Packet Source Address.....................................8 73 5. Unnumbered Addressing..........................................8 74 5.1. IGP..........................................................9 75 5.1.1. Link Local/Remote Identifiers in OSPF-TE...................9 76 5.1.2. Link Local/Remote Identifiers in IS-IS/TE..................9 77 5.2. Use of Addresses in RSVP-TE..................................9 78 5.2.1. IF_ID RSVP_HOP Object for Unnumbered Interfaces............9 79 5.2.2. Explicit Route Object (ERO)...............................10 80 5.3. Record Route Object (RRO)...................................10 81 5.4. LSP_Tunnel Interface ID Object..............................10 82 6. RSVP-TE Message Content.......................................10 83 6.1. ERO and RRO Addresses.......................................10 84 6.1.1. Strict Subobject in ERO...................................10 85 6.1.2. Loose Subobject in ERO....................................11 86 6.1.3. RRO.......................................................12 87 6.2. Forwarding Destination of Path Message with ERO.............12 88 7. GMPLS Control Plane...........................................12 89 7.1. Control Channel Separation..................................12 90 7.2. Native and Tunneled Control Plane...........................13 91 7.3. Separation of Control and Data Plane Traffic................13 92 8. Security Considerations.......................................13 93 9. Full Copyright Statement......................................13 94 10. Intellectual Property........................................14 95 11. Acknowledgement..............................................14 96 12. Authors' Addresses...........................................15 97 13. Contributors.................................................15 98 14. References...................................................16 99 14.1. Normative References.......................................16 100 14.2. Informative References.....................................17 102 Changes from version -00 to version -01: 104 - Used conventions of section 2 throughout draft 106 - Removed dedicated sections for IS-IS: discussed in unified section 107 on IGP 109 - Removed dedicated sections for IPv6: text now addresses v4 and v6 111 - Cleaned up all sections 113 - Separated references into informational and normative sections 115 1. Introduction 117 This document describes explains and clarifies addressing and 118 messaging in networks that use GMPLS [RFC3945] as their control 119 plane. For the purposes of this document it is assumed that there is 120 a one-to-one correspondence between control plane and data plane 121 entities. That is, each data plane switch has a unique control plane 122 presence responsible for participating in the GMPLS protocols, and 123 that each such control plane presence is responsible for a single 124 data plane switch. The combination of control plane and data plane 125 entities is referred to as a Label Switching Router (LSR). Various 126 more complex deployment scenarios can be constructed, but these are 127 out of scope of this document. 129 2. Conventions Used in This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Terminology 137 Note that the term 'Router ID' is used in two contexts within GMPLS. 138 It may refer to an identifier for a participant in a routing 139 protocol, or it may be an identifier for an LSR that participates in 140 TE routing. These could be considered as the control plane and data 141 plane contexts. 143 In this document, the contexts are distinguished by the following 144 definitions. 146 Loopback address - A loopback address is a stable IP address of the 147 advertising router that is always reachable if there is any IP 148 connectivity to it [RFC3630]. Thus, for example, an IPv4 127/24 149 address is excluded from this definition. 151 TE Router ID - A stable IP address of an LSR that is always reachable 152 if there is any IP connectivity to the LSR, e.g., a loopback address. 153 The most important requirement is that the address does not become 154 unusable if an interface on the LSR is down [RFC3477]. 156 Router ID - The OSPF protocol version 2 [RFC2328] defines the Router 157 ID to be a 32-bit network unique number assigned to each router 158 running OSPF. IS-IS [RFC1195] includes a similar concept in the 159 System ID. This document describes both concepts as the "Router ID" 160 of the router running the routing protocol. The Router ID is not 161 required to be a reachable IP address, although an operator MAY set 162 it to a reachable IP address on the same system. 164 TE link � "A TE link is a representation in the IS-IS/OSPF Link State 165 advertisements and in the link state database of certain physical 166 resources, and their properties, between two GMPLS nodes." [RFC3945] 168 Data plane node � A vertex on the TE graph. It is a data plane 169 switch or router. Data plane nodes are connected by TE links which 170 are constructed from physical data links. A data plane node is 171 controlled through some combination of management and control plane 172 actions. A data plane node may be under full or partial control of a 173 control plane node. 175 Control plane node - A GMPLS protocol speaker. It may be part of a 176 data plane switch or may be a separate computer. Control plane nodes 177 are connected by control channels which are logical connectionless or 178 connection-oriented paths in the control plane. A control plane node 179 is responsible for controlling zero, one or more data plane nodes. 181 Interface ID � The Interface ID is defined in [RFC3477] and in 182 section 9.1 of [RFC3471]. 184 4. Numbered Addressing 186 When numbered addressing is used, addresses are assigned to each node 187 and link in both control and data planes in GMPLS networks. A TE 188 Router ID is defined to identify the LSR for TE purposes. It is a 189 requirement stated in [RFC3477] that the TE Router ID MUST be a 190 reachable address in the control plane. 192 The reason why the TE Router ID must be a reachable IP address is 193 because in GMPLS, control and data plane names /addresses are not 194 completely separated. An Explicit Route Object (ERO) signaled as a 195 part of a Label Switched Path (LSP) setup message contains an LSP 196 path specified in data plane addresses, namely TE Router IDs and TE 197 link IDs. The message needs to be forwarded as IP/RSVP packet 198 between LSRs that manage data plane nodes along the path. Hence, 199 each LSR along the path needs to resolve the next hop data plane 200 address into the next hop control plane address before the message 201 could be forwarded to the next hop. Generally speaking there is a 202 need for a module/protocol that discovers and manages control plane/ 203 data plane address bindings for the address spaces to be completely 204 separated. In this case, the TE Router ID could be just a network 205 unique number. Mandating that TE Router ID be a reachable IP address 206 eliminates the need of the mentioned above module � the next hop data 207 plane TE Router ID could be used as a destination for IP packets 208 encapsulating the LSP setup (RSVP Path) message. Note that every TE 209 link ID could always be resolved to the link originating TE Router 210 ID. 212 An IP address MAY also be assigned to each physical interface 213 connected to the control plane network. Both numbered and unnumbered 214 links in the control plane MAY be supported. The control channels 215 are advertised by the routing protocol as normal links, which allows 216 the routing of RSVP-TE and other control messages between the LSRs 217 over the control plane network. 219 A physical interface address or a physical interface identifier is 220 assigned to each physical interface connected to the data plane. An 221 interface address or an interface identifier is logically assigned to 222 each TE-link end associated with the physical data channel in the 223 GMPLS domain. A TE link may be installed as a logical interface. 225 A numbered link is identified by a network unique identifier (e.g., 226 an IP address) and an unnumbered link is identified by the 227 combination of TE Router ID and a node-unique Interface ID. The 228 existence of both numbered and unnumbered links in the data plane 229 SHOULD be accepted. The recommended addressing for the numbered and 230 unnumbered links is also suggested in this document. 232 4.1. Interior Gateway Protocols 234 We address in this section unnumbered addressing using two Interior 235 Gateway Protocols (IGPs) that have extensions defined for GMPLS: 236 OSPF-TE and IS-IS/TE [RFC3784]. 238 4.1.1. Router Address 240 The Router Address is advertised in OSPF-TE using the Router Address 241 TLV structure [RFC3630]. 243 It is referred to as the Addressing Router that is advertised in IS- 244 IS [RFC1195]. 246 The IGP protocols use this as a means to advertise the TE Router ID. 247 The TE Router ID is used in constrained-based path computation. 249 4.1.2. Link ID sub-TLV 251 The Link ID sub-TLV [RFC3630] advertises the Router ID of the remote 252 end of the TE link. For point-to-point links, this is the Router ID 253 of the neighbor. Multi-access links are left for further study. 255 Note that there is no correspondence in IS-IS to the Link ID sub-TLV 256 in OSPF-TE. 258 4.1.3. Local Interface IP Address 260 The Local Interface IP Address is advertised in: 261 - the Local Interface IP Address sub-TLV in OSPF-TE 262 - the IPv4 Interface Address sub-TLV in IS-IS/TE 264 This is the ID of the local end of the numbered TE link. It MUST be 265 a network unique number. 267 4.1.4. Remote Interface IP Address 269 The Remote Interface IP Address is advertised in: 270 - the Remote Interface IP Address sub-TLV in OSPF-TE 271 - the IPv4 Neighbor Address sub-TLV in IS-IS/TE 273 This is the ID of the remote end of the numbered TE link. It MUST be 274 a network unique number. 276 4.2. Use of Addresses in RSVP-TE 278 4.2.1. IP Tunnel End Point Address in Session Object 280 The IP tunnel end point address of the Session Object is either an 281 IPv4 or IPv6 address. 283 It is RECOMMENDED that the IP tunnel endpoint address in the Session 284 Object [RFC3209] be set to the TE Router ID of the egress since the 285 TE Router ID is a unique routable ID per node. 287 Alternatively, the tunnel end point address MAY also be set to the 288 destination data plane address if the ingress knows that address or 289 the TE Router ID. 291 4.2.2. IP Tunnel Sender Address in Sender Template Object 293 The IP tunnel sender address of the Sender Template Object is also 294 either an IPv4 or IPv6 address. 296 It is RECOMMENDED that the IP tunnel sender address in the Sender 297 Template Object [RFC3209] specifies the TE Router ID of the ingress 298 since the TE Router ID is a unique routable ID per node. 300 Alternatively, the tunnel sender address MAY also be set to the 301 sender data plane address or the TE Router ID. 303 4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces 305 1. IPv4/IPv6 Next/Previous Hop Address: the IPv4/IPv6 Next/Previous 306 Hop Address [RFC3473] in the Path and Resv messages specifies the 307 IP reachable address of the control plane interface used to send 308 those messages, or the TE Router ID of the node that is sending 309 those messages. 311 2. IPv4/IPv6 address in Value Field of the Interface_ID TLV: In both 312 the Path and Resv messages, the IPv4/IPv6 address in the value 313 field of TLV [RFC3471] specifies the associated data plane local 314 interface address of the downstream data channel belonging to the 315 node sending the Path message and receiving the Resv message. In 316 the case of bi-directional LSPs, if the interface upstream is 317 different from that downstream, then another TLV including the 318 local interface address of the upstream data channel belonging to 319 the node sending the Path message and receiving the Resv message 320 MAY be also added to the TLV for downstream. Note that 321 identifiers of both downstream and upstream data channels are 322 specified in each TLV from the viewpoint of the sender of the 323 Path message, in both the sent Path and received Resv messages. 325 4.2.4. Explicit Route Object (ERO) 327 The IPv4/IPv6 address in the ERO provides a data-plane identifier of 328 an abstract node, TE node or TE link to be part of the signaled LSP. 330 We describe in section 6 the choice of addresses in the ERO. 332 4.2.5. Record Route Object (RRO) 334 The IPv4/IPv6 address in the RRO provides a data-plane identifier of 335 either a TE node or TE link that is part of the established LSP. 337 We describe in section 6 the choice of addresses in the RRO. 339 4.3. IP Packet Destination Address 341 The IP destination address of the packet that carries the RSVP-TE 342 message is a control-plane reachable address of the next hop or 343 previous hop node along the LSP. It is RECOMMENDED that a stable 344 control plane IP address of the next/previous hop node be used as an 345 IP destination address in RSVP-TE message. 347 A Path message is sent to the next hop node. It is RECOMMENDED that 348 the TE router ID of the next hop node be used as an IP destination 349 address in the packet that carries the RSVP-TE message. 351 A Resv message is sent to the previous hop node. It is RECOMMENDED 352 that the IP destination of a Resv message be any of the following: 353 - The IP source address of the received IP packet containing the 354 Path message, 355 - A stable IP address of the previous node (found out by consulting 356 the TED and referencing the upstream data plane interface, 357 - The value in the received phop field. 359 4.4. IP Packet Source Address 361 The IP source address of the packet that carries the RSVP-TE message 362 MUST be a reachable address of the node sending the RSVP-TE message. 363 It is RECOMMENDED that a stable IP address of the node be used as an 364 IP source address of the IP packet. In case the IP source address of 365 the received IP packet containing the Path message is used as the IP 366 destination address of the Resv message, setting a stable IP address 367 in the Path message is beneficial for reliable control-plane 368 transmission. This allows for robustness when one of control-plane 369 interfaces is down. 371 5. Unnumbered Addressing 373 In this section, we describe unnumbered addressing used in GMPLS to 374 refer to different objects and their significance. Unnumbered 375 addressing is supported for a data plane. 377 5.1. IGP 379 Since GMPLS caters to PSC and non-PSC links, a few enhancements have 380 been made to the existing OSPF-TE and ISIS-TE protocols. The routing 381 enhancements for GMPLS are defined in [GMPLS-RTG], [RFC3784] and 382 [GMPLS-OSPF]. 384 5.1.1. Link Local/Remote Identifiers in OSPF-TE 386 Link Local/Remote Identifiers advertise IDs of an unnumbered TE 387 link's local and remote ends respectively. Those are numbers unique 388 within the scopes of the advertising LSR and the LSR managing the 389 remote end of the link respectively. Note that these numbers are not 390 network unique and therefore could not be used as TE link end 391 addresses on their own. An unnumbered TE link end address is 392 comprised of a Router ID associated with the link local end, followed 393 by the link local identifier [GMPLS-OSPF]. 395 5.1.2. Link Local/Remote Identifiers in IS-IS/TE 397 Link local/remote identifiers in IS-IS/TE are exchanged in the 398 Extended Local Circuit ID field of the "Point-to-Point Three-Way 399 Adjacency" [RFC3373] IS-IS Option type. The same discussion in 5.1.1 400 applies here. 402 5.2. Use of Addresses in RSVP-TE 404 An unnumbered address used for data plane identification consists of 405 the TE router ID and the associated interface ID. 407 5.2.1. IF_ID RSVP_HOP Object for Unnumbered Interfaces 409 The interface ID field in the IF_INDEX TLV specifies the interface of 410 the data channel for that unnumbered interface. 412 In both the Path message and the Resv message, the value of the 413 interface ID in the IF_INDEX TLV specifies the associated local 414 interface ID of the downstream data channel belonging to the node 415 sending the Path message and receiving the Resv message. In case of 416 bi-directional LSPs, if the interface upstream is different from that 417 downstream, then another IF_INDEX TLV including the local interface 418 ID of the upstream data channel belonging to the node sending the 419 Path message and receiving the Resv message MAY be also added to the 420 IF_INDEX TLV for downstream. Note that identifiers of both 421 downstream and upstream data channels are specified in each IF_INDEX 422 TLV from the viewpoint of the sender of the Path message, in both 423 sent Path and received Resv messages. 425 5.2.2. Explicit Route Object (ERO) 427 For unnumbered interfaces in the ERO, the interface ID is either the 428 incoming or outgoing interface of the TE-link w/r to the GMPLS- 429 capable LSR. 431 We describe in section 6 the choice of addresses in the ERO. 433 5.3. Record Route Object (RRO) 435 For unnumbered interfaces in the RRO, the interface ID is either the 436 incoming or outgoing interface of the TE-link w/r to the GMPLS- 437 capable LSR. 439 We describe in section 6 the choice of addresses in the RRO. 441 5.4. LSP_Tunnel Interface ID Object 443 The LSP_TUNNEL_INTERFACE_ID Object includes the LSR's Router ID and 444 Interface ID as described in [RFC3477] to specify an unnumbered 445 Forward Adjacency Interface ID. The Router ID of the GMPLS-capable 446 LSR MUST be set to the TE router ID. 448 6. RSVP-TE Message Content 450 6.1. ERO and RRO Addresses 452 6.1.1. Strict Subobject in ERO 454 Implementations making limited assumptions about the content of an 455 ERO when processing a received Path message may cause 456 interoperability issues. 458 A subobject in the Explicit Route Object (ERO) includes an address 459 specifying an abstract node (i.e., a group of nodes), a simple 460 abstract node (i.e., a specific node), or a specific interface of a 461 TE-link in the data plane, depending on the level of control required 462 [RFC3209]. 464 In case one subobject is strict, any of the following options are 465 valid: 466 1. Address or AS number specifying a group of nodes 467 2. TE Router ID 468 3. Incoming TE link ID 469 4. Outgoing TE link ID optionally followed by one or two Label sub- 470 objects 472 5. Incoming TE link ID and Outgoing TE link ID optionally followed by 473 one or two Label sub-objects 474 6. TE Router ID and Outgoing TE link ID optionally followed by one or 475 two Label sub-objects 476 7. Incoming TE link ID, TE Router ID and Outgoing TE link ID 477 optionally followed by one or two Label sub-objects 479 The label value that identifies a single unidirectional resource 480 between two nodes may be different from the perspective of upstream 481 and downstream nodes. This is typical in the case of fiber 482 switching, because the label value is a number indicating the 483 port/fiber. This is also possible in case of lambda switching, 484 because the label value is a number indicating the lambda, but may 485 not be the value directly indicating the wavelength value (e.g., 1550 486 nm). 488 The value of a label in RSVP-TE object MUST indicate the value from 489 the perspective of the sender of the object/TLV [RFC3471]. This rule 490 MUST be applied to all types of object/TLV. 492 Therefore, the label field in the Label ERO subobject MUST include 493 the value of the label for the upstream node�s identification of the 494 resource. 496 6.1.2. Loose Subobject in ERO 498 There are two differences between Loose and Strict subobject. 500 A subobject marked as a loose hop in an ERO MUST NOT be followed by a 501 subobject indicating a label value [RFC3473]. 503 A subobject marked as a loose hop in an ERO SHOULD never include an 504 identifier (i.e., address or ID) of outgoing interface. 506 There is no way to specify in the ERO whether a subobject is 507 associated with the incoming or outgoing TE link. This is 508 unfortunate because the address specified in a loose subobject is 509 used as a target for the path computation, and there is a big 510 difference for the path selection process whether the intention is to 511 reach the target node over the specified link (the case of incoming 512 TE link) or to reach the node over some other link, so that it would 513 be possible to continue the path to its final destination over the 514 specified link (the case of outgoing TE link). 516 In the case where a subobject in an ERO is marked as a loose hop and 517 identifies an interface, the subobject SHOULD include the address of 518 the Incoming interface specifying the TE-link in the data plane. 520 6.1.3. RRO 522 When a node adds one or more subobjects to an RRO and sends the Path 523 or the Resv message including the RRO for the purpose of recording 524 the node's addresses used for an LSP, the subobjects (i.e. number, 525 each type, and each content) added by the node SHOULD be the same in 526 the Path ERO and Resv ERO. The intention is that they report the 527 path of the LSP, and that the operator can use the results 528 consistently. At any transit node, it SHOULD be possible to 529 construct the path of the LSP by joining together the RRO from the 530 Path and the Resv messages. 532 It is also important that a whole RRO on a received Resv message can 533 be used as input to an ERO on a Path message. 535 Therefore, in case that a node adds one or more subobjects to an RRO, 536 any of the following options are valid: 537 1. TE Router ID 538 2. Incoming TE link ID 539 3. Outgoing TE link ID optionally followed by one or two Label sub- 540 objects 541 4. Incoming TE link ID and Outgoing TE link ID optionally followed by 542 one or two Label sub-objects 543 5. TE Router ID and Outgoing TE link ID optionally followed by one or 544 two Label sub-objects 545 6. Incoming TE link ID, TE Router ID and Outgoing TE link ID 546 optionally followed by one or two Label sub-objects 548 Option (4) is RECOMMENDED considering the importance of the record 549 route information to the operator. 551 6.2. Forwarding Destination of Path Message with ERO 553 The final destination of the Path message is the Egress node that is 554 specified by the tunnel end point address in the Session object. 555 The Egress node MUST NOT forward the corresponding Path message 556 downstream, even if the ERO includes the outgoing interface ID of the 557 Egress node for the Egress control [RFC4003]. 559 7. GMPLS Control Plane 561 7.1. Control Channel Separation 563 In GMPLS, a control channel can be separated from the data channel 564 and there is not necessarily a one-to-one association of a control 565 channel to a data channel. Two adjacent nodes may have multiple IP 566 hops between them in the control plane. 568 There are two broad types of separated control planes: native and 569 tunneled. These differ primarily in the nature of encapsulation used 570 for signaling messages, which also results in slightly different 571 address handling with respect to the control plane address. 573 7.2. Native and Tunneled Control Plane 575 It is RECOMMENDED that all implementations support a native control 576 plane. 578 If the control plane interface is unnumbered, the RECOMMENDED value 579 for the control plane address is the TE Router-ID. 581 For the case where two adjacent nodes have multiple IP hops between 582 them in the control plane, then as stated in section 9 of [RFC3945], 583 implementations SHOULD use the mechanisms of section 8.1.1 of [MPLS- 584 HIER] whether they use LSP Hierarchy or not. Note that section 8.1.1 585 of [MPLS-HIER] applies for "FA-LSP" as stated in that section but 586 also to "TE-LINK" for the case where a normal TE link is used. 587 Note also that a hop MUST NOT decrement the TTL of the received RSVP- 588 TE message. 590 For a tunneled control plane, the inner RSVP and IP messages traverse 591 exactly one IP hop. The IP TTL of the outermost IP header SHOULD be 592 the same as for any network message sent on that network. 593 Implementations receiving RSVP-TE messages on the tunnel interface 594 MUST NOT compare the RSVP TTL to either of the IP TTLs received. 595 Implementations MAY set the RSVP TTL to be the same as the IP TTL in 596 the innermost IP header. 598 7.3. Separation of Control and Data Plane Traffic 600 Data traffic MUST NOT be transmitted through the control plane. 602 8. Security Considerations 604 In the interoperability testing we conducted, the major issue we 605 found was the use of control channels for forwarding data. This was 606 due to the setting of both control and data plane addresses to the 607 same value in PSC (Packet-Switching Capable) equipment. This led to 608 major problems that could be avoided simply by keeping the addresses 609 for the control and data plane separate. 611 9. Full Copyright Statement 612 Copyright (C) The Internet Society (2005). 614 This document is subject to the rights, licenses and restrictions 615 contained in BCP 78, and except as set forth therein, the authors 616 retain all their rights. 618 This document and the information contained herein are provided on an 619 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 620 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 621 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 622 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 623 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 624 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 10. Intellectual Property 628 The IETF takes no position regarding the validity or scope of any 629 Intellectual Property Rights or other rights that might be claimed to 630 pertain to the implementation or use of the technology described in 631 this document or the extent to which any license under such rights 632 might or might not be available; nor does it represent that it has 633 made any independent effort to identify any such rights. Information 634 on the IETF's procedures with respect to rights in IETF Documents can 635 be found in BCP 78 and BCP 79. 637 Copies of IPR disclosures made to the IETF Secretariat and any 638 assurances of licenses to be made available, or the result of an 639 attempt made to obtain a general license or permission for the use of 640 such proprietary rights by implementers or users of this 641 specification can be obtained from the IETF on-line IPR repository at 642 http://www.ietf.org/ipr. 644 The IETF invites any interested party to bring to its attention any 645 copyrights, patents or patent applications, or other proprietary 646 rights that may cover technology that may be required to implement 647 this standard. Please address the information to the IETF at ietf- 648 ipr@ietf.org. 650 11. Acknowledgement 652 The authors would like to thank Adrian Farrel for the helpful 653 discussions and the feedback he gave on the document. We'd also like 654 to thank Jonathan Sadler and Hidetsugu Sugiyama for their feedback. 656 12. Authors' Addresses 658 Kohei Shiomoto 659 NTT Network Service Systems Laboratories 660 3-9-11 Midori 661 Musashino, Tokyo 180-8585 662 Japan 663 Email: shiomoto.kohei@lab.ntt.co.jp 665 Rajiv Papneja 666 Isocore Corporation 667 12359 Sunrise Valley Drive, Suite 100 668 Reston, Virginia 20191 669 United States of America 670 Phone: +1-703-860-9273 671 Email: rpapneja@isocore.com 673 Richard Rabbat 674 Fujitsu Labs of America, Inc. 675 1240 East Arques Ave, MS 345 676 Sunnyvale, CA 94085 677 United States of America 678 Phone: +1-408-530-4537 679 Email: richard.rabbat@us.fujitsu.com 681 13. Contributors 683 Yumiko Kawashima 684 NTT Network Service Systems Lab 685 Email: kawashima.yumiko@lab.ntt.co.jp 687 Ashok Narayanan 688 Cisco Systems 689 Email: ashokn@cisco.com 691 Eiji Oki 692 NTT Network Service Systems Laboratories 693 Midori 3-9-11 694 Musashino, Tokyo 180-8585, Japan 695 Email: oki.eiji@lab.ntt.co.jp 697 Lyndon Ong 698 Ciena Corporation 699 Email: lyong@ciena.com 701 Vijay Pandian 702 Sycamore Networks 703 Email: Vijay.Pandian@sycamorenet.com 705 Hari Rakotoranto 706 Cisco Systems 707 Email: hrakotor@cisco.com 709 14. References 711 14.1. Normative References 713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels," BCP 14, IETF RFC 2119, March 1997. 716 [RFC2328] Moy, J., "OSPF Version 2," RFC 2328, April 1998. 718 [RFC3209] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP 719 Tunnels," RFC 3209, December 2001. 721 [RFC3471] Berger, L., ed., "Generalized Multi-Protocol Label 722 Switching (GMPLS) Signaling Functional Description," RFC 723 3471, January 2003. 725 [RFC3473] Berger, L., ed. "Generalized Multi-Protocol Label 726 Switching (GMPLS) Signaling Resource ReserVation 727 Protocol-Traffic Engineering (RSVP-TE) Extensions," RFC 728 3473, January 2003. 730 [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 731 in Resource ReSerVation Protocol - Traffic Engineering 732 (RSVP-TE)," RFC 3477, January 2003. 734 [RFC3630] Katz, D., Kompella, K. et al., "Traffic Engineering (TE) 735 Extensions to OSPF Version 2," RFC 3630, September 2003. 737 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, IETF 738 RFC 3667, February 2004. 740 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 741 Technology", BCP 79, IETF RFC 3668, February 2004. 743 [RFC3945] Mannie, E., ed., "Generalized Multi-Protocol Label 744 Switching (GMPLS) Architecture," RFC 3945, October 2004. 746 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 747 Control," RFC 4003, February 2005. 749 [GMPLS-OSPF] K. Kompella, Y. Rekhter (Eds.), "OSPF Extensions in 750 Support of Generalized Multi-protocol Label Switching," 751 work in progress, draft-ietf-ccamp-gmpls-ospf-gmpls- 752 extensions-12.txt, October 2003. 754 [GMPLS-RTG] K. Kompella, Y. Rekhter (Eds.), "Routing Extensions in 755 Support of Generalized Multi-protocol Label Switching," 756 draft-ietf-ccamp-gmpls-routing-09.txt, October 2003. 758 [MPLS-HIER] Kompella, K. and Rekhter, Y., "LSP Hierarchy with 759 Generalized MPLS TE," work in progress, draft-ietf-mpls- 760 lsp-hierarchy-08.txt, March 2002. 762 14.2. Informative References 764 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 765 Dual Environments," RFC 1195, December 1990. 767 [RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for 768 Intermediate System to Intermediate System (IS-IS) Point- 769 to-Point Adjacencies," RFC 3373, September 2002. 771 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 772 System (IS-IS) Extensions for Traffic Engineering (TE)," 773 RFC 3784, June 2004.