CCAMP Working Group Kohei Shiomoto (NTT) Internet Draft Rajiv Papneja (ISOCORE) Expires: July 2005 Richard Rabbat (Fujitsu) Category: Best Current Practice January 2005 Addressing and Messaging in Generalized Multi-Protocol Label Switching (GMPLS) Networks: Best Practices draft-shiomoto-ccamp-gmpls-addressing-00.txt Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes best practices in addressing and messaging in Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim of this document is to facilitate and ensure better interworking of GMPLS-capable Label Switching Routers (LSR) based on experience gained in deployments and interoperability testing. The document recommends best practices for the interpretation and choice of address and identifier fields within GMPLS protocols and references specific control plane usage models. It also examines some common GMPLS Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling message processing issues and recommends best practices. Expires July 2005 [Page 1] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 Table of Contents 1. Introduction...................................................3 2. Conventions Used in This Document..............................3 3. Terminology....................................................3 4. Addressing.....................................................4 4.1. OSPF-TE......................................................5 4.1.1. Router Address TLV.........................................5 4.1.2. Link ID sub TLV............................................6 4.1.3. Local Interface IP Address.................................6 4.1.4. Remote Interface IP Address................................6 4.2. ISIS-TE......................................................6 4.3. Use of Addresses in RSVP-TE..................................6 4.3.1. Session Object Destination IPv4 address....................6 4.3.2. Sender Template Object Sender IPv4 address.................6 4.3.3. IF_ID RSVP-TE_HOP Object for Numbered Interfaces...........7 4.3.4. Explicit Route Object (ERO)................................7 4.3.5. Record Route Object (RRO)..................................7 4.4. IP Packet Destination Address................................8 4.5. IP Packet Source Address.....................................8 5. Unnumbered Addressing..........................................8 5.1. OSPF-TE......................................................9 5.1.1. Link Local/Remote Identifiers..............................9 5.2. ISIS-TE......................................................9 5.3. Use of Addresses in RSVP-TE..................................9 5.3.1. IF ID RSVP-TE_HOP Object for Unnumbered Interfaces.........9 5.3.2. Explicit Route Object (ERO)................................9 5.4. Record Route Object (RRO)...................................10 5.5. LSP_Tunnel Interface ID Object..............................10 5.6. IPv6 Addressing.............................................10 6. RSVP-TE Message Content.......................................10 6.1. ERO and RRO Addresses.......................................10 6.1.1. Strict Subobject in ERO...................................10 6.1.2. Loose Subobject in ERO....................................11 6.1.3. RRO.......................................................12 6.2. Forwarding Destination of Path Message with ERO.............13 7. GMPLS Control Plane...........................................13 7.1. Control Channel Separation..................................13 7.2. Native Control Plane........................................13 7.3. Tunneled Control Plane......................................14 7.4. Separation of Control and Data Plane Traffic................15 8. Security Considerations.......................................16 9. Full Copyright Statement......................................16 10. Intellectual Property........................................16 11. Acknowledgement..............................................17 12. Authors' Addresses...........................................17 13. Contributors.................................................17 14. References...................................................18 Expires July 2005 [Page 2] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 1. Introduction This document describes best practices in addressing and messaging in networks that use GMPLS [RFC3945] as their control plane. For the purposes of this document it is assumed that there is a one-to-one correspondence between control plane and data plane entities. That is, each data plane switch has a unique control plane presence responsible for participating in the GMPLS protocols, and that each such control plane presence is responsible for a single data plane switch. The combination of control plane and data plane entities is referred to as a Label Switching Router (LSR). Various more complex deployment scenarios can be constructed, but these are out of scope of this document. The document is organized as follows. Section 3 defines the used terminology including router ID. Section 4 describes addressing in OSPF-TE and RSVP-TE. Section 5 describes unnumbered addressing for these protocols as well. Section 6 describes the RSVP-TE message content including the choice of outgoing and incoming Interface IDs for ERO and RRO in the RSVP-TE message, especially for the case of loose subobject. Section 7 discusses issues related to the GMPLS control plane with respect to control channel separation and addressing in the case of native and tunneled control plane. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology Note that the term 'Router ID' is used in two contexts within GMPLS. It may refer to an identifier for a participant in a routing protocol, or it may be an identifier for an LSR that participates in TE routing. These could be considered as the control plane and data plane contexts. In this document, the contexts are distinguished by the following definitions. Loopback address - A loopback address is a stable IP address of the advertising router that is always reachable if there is any IP Expires July 2005 [Page 3] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 connectivity to it [RFC3630]. Thus a 127/24 address is excluded from this definition. TE Router ID - A stable IP address of an LSR that is always reachable if there is any IP connectivity to the LSR, e.g., a loopback address. The key attribute is that the address does not become unusable if an interface on the LSR is down [RFC3477]. Router ID - The OSPF protocol [RFC2328] defines the Router ID to be a 32-bit network unique number assigned to each router running OSPF. ISIS [RFC1195] includes a similar concept in the SystemID. This document describes both concepts as the "Router ID" of the router running the routing protocol. The Router ID is not required to be a reachable IP address, although it may be set to a reachable IP address. Data plane node - A terminal or a device in a computer network that can be uniquely identified in the network and is capable of forwarding data. Control plane node - A terminal or device in a computer network that can be uniquely identified and does not have data forwarding capability. TE node - TBD TE link - TBD TE interface - TBD Control plane node - TBD 4. Addressing Addresses are assigned to each node and link in both control and data plane in GMPLS networks. A TE Router ID is defined to identify the LSR for TE purposes. As used in [RFC3477], the TE Router ID must be a reachable address in the control plane, and is typically implemented as a loopback address. It should be advertised by the routing protocol consistent with normal use of a loopback address, so that TE Router ID can be reflected in the routing table for the control plane network. The loopback address is a stable address and is not assigned to any control or data plane interface so that any link failure will not cause the node to become unreachable. The reason why the TE Router ID must be a reachable IP address is because in GMPLS, control and data plane names /addresses are not completely separated. An Explicit Route Object (ERO) signaled as a Expires July 2005 [Page 4] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 part of a Label Switched Path (LSP) setup message contains an LSP path specified in data plane addresses, namely TE node IDs and TE link IDs. The message needs to be forwarded as IP/RSVP packet between LSRs that manage data plane nodes along the path. Hence, each LSR along the path needs to resolve the next hop data plane address into the next hop control plane address before the message could be forwarded to the next hop. Generally speaking there is a need for a module/protocol that discovers and manages control plane /data plane address bindings for the address spaces to be completely separated. In this case, the TE Router ID could be just a network unique number. Mandating that TE Router ID be a reachable IP address eliminates the need of the mentioned above module û the next hop data plane TE Router ID could be used as a destination for IP packets encapsulating the LSP setup (RSVP Path) message. Note that every TE link ID could always be resolved to the link originating TE Router ID. An IP address may also be assigned to each physical interface connected to the control plane network. Both numbered and unnumbered links in the control plane may be supported. The control channels are advertised by the routing protocol as normal links, which allows the routing of RSVP-TE and other control messages between the LSRs over the control plane network. A physical interface address or a physical interface identifier is assigned to each physical interface connected to the data plane. An interface address or an interface identifier is logically assigned to each TE-link end associated with the physical data channel in the GMPLS domain. A TE link may be installed as a physical or logical interface. A numbered link is identified by a network unique identifier (e.g., an IP address) and an unnumbered link is identified by the combination of TE Router ID and Interface ID. The existence of both numbered and unnumbered links in the data plane should be accepted. The recommended addressing for the numbered and unnumbered links is also suggested in this document. 4.1. OSPF-TE 4.1.1. Router Address TLV The Router Address TLV [RFC3630] is used for advertising the association between the advertising Router ID and its TE Router ID. The Router address TLV may be used for the CSPF calculation. This address identifies the advertising router from a CSPF calculation's point of view, i.e., it is the TE router ID associated with the advertising Router. Expires July 2005 [Page 5] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 A Router ID is also required for OSPF (non-TE) processing to identify the LSR from an OSPF protocol point of view. Note that the Router ID can be found in the header of each OSPF LSA advertised by the router. It is recommended the Router address TLV should be the same as the TE router ID for simplicity. It should, however, be possible to support interoperation with nodes that use different addresses for the Router address TLV and TE Router ID. 4.1.2. Link ID sub TLV The Link ID sub-TLV [RFC3630] advertises the TE Router ID of the remote end of TE link. For point-to-point links, this is the TE Router ID of the neighbor. For multi-access links, this is the interface address of the designated router. The Link ID is identical to the contents of the Link ID field in the Router LSA for these link types. 4.1.3. Local Interface IP Address The Local Interface IP Address sub-TLV advertises the ID of the local end of the numbered TE link. It must be network unique number and MAY be a reachable IP address. 4.1.4. Remote Interface IP Address The Remote Interface IP Address sub-TLV advertises the ID of the remote end of the numbered TE link. It must be a network unique number and may be reachable IP address. 4.2. ISIS-TE To be discussed in future version of the document. 4.3. Use of Addresses in RSVP-TE 4.3.1. Session Object Destination IPv4 address The IPv4 tunnel endpoint address in the Session Object [RFC3209] specifies the TE Router ID of the egress. 4.3.2. Sender Template Object Sender IPv4 address The IPv4 tunnel sender address in the Sender Template Object [RFC3209] specifies the TE Router ID of the ingress. Filling Session Object Destination Ipv4 Address and Sender Template Object Sender IPv4 Address fields with TE Router IDs of LSP source Expires July 2005 [Page 6] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 (ingress) and destination (egress) nodes respectively has the following advantages over IP addresses unknown to the Traffic Engineering or IDs of numbered TE links: - TE Router IDs are known in the TE database; hence, unlike other IP addresses (unknown to TE) they can be used as input for the path computation. - TE Router IDs are routable; therefore, unlike (potentially not routable) IDs of numbered TE links they can be used as destinations of targeted RSVP messages such as RSVP ResvConf. Note that RSVP Notify messages are usually sent to addresses explicitly specified in NotifyRequest objects. However, some GMPLS implementations use LSP source and destination addresses as default targets for RSVP Notify messages. 4.3.3. IF_ID RSVP-TE_HOP Object for Numbered Interfaces 1. IPv4 Next/Previous Hop Address: The IPv4 Next/Previous Hop Address [RFC3473] in Path and Resv messages specifies the IP reachable address of the control plane interface used to send those messages, or the TE router ID of the node that is sending those messages. 2. IPv4/IPv6 address in Value Field of TLV: In both the Path message and the Resv message, the IPv4/IPv6 address in the value field of TLV [RFC3471] specifies the associated data plane local interface address of the downstream data channel belonging to the node sending the Path message and receiving the Resv message. If the interface upstream is different from that downstream, then another TLV including the local interface address of the upstream data channel belonging to the node sending the Path message and receiving the Resv message may be also added to the TLV for downstream. Note that data channels of both downstream and upstream data channels are specified in each TLV from the viewpoint of the sender of the Path message, in both the sent Path message and received Resv message. 4.3.4. Explicit Route Object (ERO) The IPv4/IPv6 address in the ERO provides a data-plane identifier of an abstract node, TE node or TE link to be part of the signaled LSP. We describe in section 6 the choice of incoming or outgoing interface ID. 4.3.5. Record Route Object (RRO) Expires July 2005 [Page 7] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 The IPv4/IPv6 address in the RRO provides a data-plane identifier of either a TE node or TE link that is part of the established LSP. We describe in section 6 the choice of incoming or outgoing interface ID. 4.4. IP Packet Destination Address The IP destination address of the packet that carries the RSVP-TE message is a control-plane reachable address of the next hop or previous hop node along the LSP route. It is recommended that a stable control plane IP address of the next/previous hop node be used as an IP destination address in RSVP-TE message. A Path message is sent to the next hop node. This may not strictly specify the next hop and use CSPF calculation. As a result, the TE router ID of the next hop node will be obtained. It is recommended that the TE router ID of the next hop node be used as an IP destination address in RSVP-TE message. A Resv message is sent to the previous hop node. Choices of the IP destination of a Resv message are: - The IP source address of the received IP packet containing the Path message, - A stable IP address of the previous node (found out by consulting the TED and referencing the upstream data plane interface, - The value in the received phop field. 4.5. IP Packet Source Address The IP source address of the packet that carries the RSVP-TE message is a reachable address of the node sending the message. It is recommended that a stable IP address of the node be used as an IP source address in RSVP-TE message. In case the IP source address of the received IP packet containing the Path message is used as the IP destination address of the Resv message, setting a stable IP address in the Path message is beneficial for reliable control-plane transmission. This allows for robustness when one of control-plane interfaces is down. 5. Unnumbered Addressing In this section, we describe unnumbered addressing used in GMPLS to refer to different objects, their significance and best practices. Unnumbered addressing is supported for a data plane. Expires July 2005 [Page 8] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 5.1. OSPF-TE Since GMPLS caters to PSC and non-PSC links, a few enhancements have been made to the existing OSPF-TE and ISIS-TE protocols. The routing enhancements for GMPLS are defined in [GMPLS-Rtg] and [GMPLS-OSPF]. 5.1.1. Link Local/Remote Identifiers Link Local/Remote Identifiers advertise IDs of an unnumbered TE link's local and remote ends respectively. Those are numbers unique within the scopes of the advertising LSR and the LSR managing link remote end respectively. Note that these numbers are not network unique and therefore could not be used as TE link end addresses on their own. An unnumbered TE link end address is comprised of a TE Router ID associated with the link local end followed by the link local identifier [GMPLS-OSPF]. 5.2. ISIS-TE To be discussed in future version of the document. 5.3. Use of Addresses in RSVP-TE An unnumbered address used for data plane identification consists of the TE router ID and the associated interface ID. 5.3.1. IF ID RSVP-TE_HOP Object for Unnumbered Interfaces The interface ID field in the IF_INDEX TLV specifies the interface of the data channel for that unnumbered interface. In both the Path message and the Resv message, the value of the interface ID in the IF_INDEX TLV specifies the associated local interface ID of the downstream data channel belonging to the node sending the Path message and receiving the Resv message. If the interface upstream is different from that downstream, then another IF_INDEX TLV including the local interface ID of the upstream data channel belonging to the node sending the Path message and receiving the Resv message may be also added to the IF_INDEX TLV for downstream. Note that both downstream and upstream data channels are specified in each IF_INDEX TLV from the viewpoint of the sender of the Path message, in both sent Path message and received Resv message. 5.3.2. Explicit Route Object (ERO) Expires July 2005 [Page 9] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 The interface ID field in the ERO specifies incoming and/or outgoing interface of the TE-link to be used in nodes on the LSP route in the data plane. We describe in section 6 the choice of incoming or outgoing interface ID. 5.4. Record Route Object (RRO) The interface ID field in the RRO specifies incoming and/or outgoing interface of the TE-link actually used in nodes on the LSP route in the data plane. We describe in section 6 the choice of incoming or outgoing interface ID. 5.5. LSP_Tunnel Interface ID Object The LSP_TUNNEL_INTERFACE_ID Object includes the LSR's Router ID and Interface ID as described in [RFC3477] to specify a Forward Adjacency Interface ID. The LSR's Router ID is the TE router ID. 5.6. IPv6 Addressing TBD: IPv6 control planes and IPv6 data planes 6. RSVP-TE Message Content 6.1. ERO and RRO Addresses 6.1.1. Strict Subobject in ERO The IPv4 prefix subobject or IPv6 prefix subobject in the Explicit Route Object (ERO) includes an address specifying an abstract node (i.e., a group of nodes), a simple abstract node (i.e., a specific node), or a specific interface of a TE-link in the data plane in the case of strict subobject [RFC3209]. In the case where Interface Address is included, it is recommended to include in the IPv4/IPv6 prefix subobject the address of the Incoming interface if it is not followed by the Label subobject as section 4.2.2 of RFC3209 implies; otherwise, it should include the address of Outgoing interface if it is followed by the Label subobject as section 5.1.1 of RFC3473 specifies. This is the same in case of unnumbered. The Unnumbered Interface ID Subobject [RFC3477] in EXPLICIT_ROUTE object includes the Interface ID specifying the TE-link in the data plane. Expires July 2005 [Page 10] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 It is recommended that the Unnumbered Interface ID Subobject include the ID of Incoming interface if it is not followed by the Label subobject and should include the ID of Outgoing interface if it is followed by the Label subobject. The label value of the identical unidirectional (i.e. either downstream or upstream) resource between the upstream node and the neighbor downstream node from the perspective of the upstream node may be different from the perspective of downstream node. This is typical in case of FSC, because the label value is the number indicating the port/fiber. This is possible in case of LSC, because the label value is the number indicating the lambda but may not be the value directly indicating the wavelength value (e.g., 1550 nm). The value of label MUST indicate the value from the perspective of the sender of the object/TLV [RFC3471]. This rule MUST be applied to all types of object/TLV. Therefore, the label field in Label ERO subobject MUST include the value of the label for the upstream node side of the resource. 6.1.2. Loose Subobject in ERO A subobject in an ERO may be marked as a loose hop [RFC3209]. In this case the content may be an IPv4 or IPv6 prefix subobject that specifies the address of an abstract node (i.e., a group of nodes), or a simple abstract node (i.e., a specific node). In the case where a simple abstract node is specified, an IPv4 or IPv6 prefix subobject includes TE node ID. There may be a special case where the Interface ID is specified in the Loose subobject in the ERO in order to control on what interface the path is set up. Here, there is no way to specify in ERO whether a subobject is associated with the incoming or outgoing TE link. This is unfortunate because the address specified in a loose subobject is used as a target for the path computation, and there is a big difference for the path selection process whether the intention is to reach the target node over the specified link (the case of incoming TE link) or to reach the node over some other link, so that it would be possible to continue the path to its final destination over the specified link (the case of outgoing TE link). In the case where the IPv4 prefix subobject or the IPv6 prefix subobject in the ERO is marked as a loose hop and specially specifies an interface, the subobject SHOULD include the address of the Incoming interface specifying the TE-link in the data plane. Expires July 2005 [Page 11] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 In the special case where the Unnumbered Interface ID Subobject with Loose bit set is included in ERO, the subobject should include the ID of the Incoming interface specifying the TE-link in the data plane. A subobject marked as a loose hop in ERO should never include an identifier (i.e., address or ID) of outgoing interface. 6.1.3. RRO The IPv4 address Subobject or the IPv6 address Subobject in the Record Route Object (RRO) in the PATH message SHOULD include the address of the Outgoing interface specifying the TE-link in the data plane. The IPv4 address Subobject or the IPv6 address Subobject in the Record Route Object (RRO) in the RESV message SHOULD include the address of the Incoming interface specifying the TE-link in the data plane. The Unnumbered Interface ID subobject in the Record Route Object in the PATH message SHOULD also include the interface ID of the Outgoing interface specifying the TE-link in the data plane. The Unnumbered Interface ID subobject in the Record Route Object in the RESV message SHOULD also include the interface ID of the Incoming interface specifying the TE-link in the data plane. Incoming and outgoing always refer to the direction of data on a unidirectional LSP. The label value of the identical unidirectional (i.e. either downstream or upstream) resource between the upstream node and the neighbor downstream node from the perspective of the upstream node may be different from the perspective of the downstream node. The value of the label must indicate the value from the perspective of the sender of the object/TLV [RFC3471]. This rule must be applied to all types of object/TLV. Therefore, the label field in the Label RRO subobject in the Path message must include the value of the label for the upstream node side of the resource; the label field in the Label RRO in the Resv message must include the value of the label for the downstream node side of the resource. The IPv4/IPv6 address Subobject in the Record Route Object (RRO) may include TE node ID. However, it is recommended to include the Expires July 2005 [Page 12] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 interface ID rather than the TE node ID, because the interface ID has more information and is more helpful from the viewpoint of maintenance than node ID. 6.2. Forwarding Destination of Path Message with ERO The final destination of the Path message is the Egress node that is specified by the tunnel end point address in the Session object. The Egress node must not forward the corresponding Path message downstream. In the case where the EXPLICIT_ROUTE object (ERO) includes the Interface address or Interface ID as the last element for the Egress control [EGR-CNT], the Egress node MUST NOT forward the corresponding Path message downstream. 7. GMPLS Control Plane 7.1. Control Channel Separation In GMPLS, a control channel can be separated from the data channel and there is not necessarily a one-to-one association of a control channel to a data channel. Two adjacent nodes may have multiple IP hops between them in the control plane. In this discussion, the "control plane address" identifies a node to other nodes in the control plane. It MUST be used in RSVP-TE Hop objects as the Next/Previous Hop addresses, as the IP source/destination addresses in the innermost IP header of all signaling messages, and to identify neighbors for reliable messaging [RFC2961]. Nodes can have multiple control plane addresses. There are two broad types of separated control planes: native and tunneled. These differ primarily in the nature of encapsulation used for signaling messages, which also results in slightly different address handling with respect to the control plane address. 7.2. Native Control Plane A native control plane runs directly over a physical interface. Signaling packets are encapsulated in a single IP header and necessary Layer-2 headers in order for the source and destination interfaces to communicate at an IP layer. All implementations MUST support a native control plane. Native control planes can run out-of- band (e.g. over an Ethernet or other interface), or in-fiber. Expires July 2005 [Page 13] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 The control plane address is set to the IP address of the physical interface. This control plane address MUST be used as the source (destination, respectively) address in the IP header of all RSVP-TE messages sent from (to) the node, and in the Hop objects as above. If the control plane interface is unnumbered, the RECOMMENDED value for the control plane address is the TE Router-ID. Implementations MUST support addressing and sending messages to arbitrary neighbor control plane addresses (either configured or discovered), such as private addresses or TE Router-ID. Implementations MUST support receiving messages addressed to their TE Router-ID on all point-to-point control interfaces, numbered or unnumbered. Implementations MAY support receiving messages addressed to their TE Router-ID on broadcast or NBMA interfaces, perhaps using some form of proxy-ARP for reachability. For the case where two adjacent nodes have multiple IP hops between them in the control plane and IP tunneling is not set for the control channel, implementations MUST use the mechanisms of section 8.1.1 of [HIERARCHY] in addition to the mechanisms of section 7.18 of [RFC3945]. Note that section 8.1.1 of [Error! Bookmark not defined.] applies to this case by replacing all instances of the words "FA-LSP" (Forwarding Adjacency) with "TE-LINK" in case the LSP is not tunneled through an FA-LSP but a normal TE-link. Several mechanisms for the case are described below. All RSVP-TE messages MUST NOT include the Router Alert Option. PathErr message SHOULD contain an IF_ID RSVP_HOP object. (Note: a PathErr does not normally carry an IF_ID RSVP_HOP object.) With respect to Time-To-Live (TTL), one should note that messages may traverse multiple IP hops. The IP TTL applied to RSVP-TE messages sent on a separated control channel SHOULD be the same as for any network message sent on that network. Specific values like 1 or 255 MAY be used if specific aims are desired, e.g. ensuring all RSVP messages travel only one hop. Implementations sending RSVP messages on a separated control plane SHOULD explicitly set the IP TTL for every message generated. Implementations receiving RSVP-TE messages on a separated control plane MUST NOT compare the RSVP and IP TTL. Instead, checking received IF_ID RSVP_HOP object in the way described in section 8.1.1 of [Error! Bookmark not defined.] is essential. 7.3. Tunneled Control Plane Expires July 2005 [Page 14] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 A tunneled control plane runs on a virtual point-to-point tunnel interface, which in turn may use an underlying physical interface to reach the neighbor. RSVP-TE packets (including RSVP and IP headers) are encapsulated in an additional Layer-3 header which is used to transit a control network. A common example of tunnel technologies is GRE encapsulation [RFC2784]. In the common case of GRE tunnel encapsulation, the physical interface IP address is used in the outermost IP header and serves to route the signaling packet through the DCN. The control plane address is set to the address of the virtual tunnel interface. This control plane address is used in the innermost IP header, and in other uses for RSVP as discussed above. If the virtual tunnel interface is unnumbered, the RECOMMENDED value for the control plane address is the TE Router-ID. For a tunneled control plane, the inner RSVP and IP messages traverse exactly one IP hop. The IP TTL of the outermost IP header SHOULD be the same as for any network message sent on that network. Implementations receiving RSVP-TE messages on the tunnel interface MUST NOT compare the RSVP TTL to either of the IP TTLs received. Implementations MAY set the The RSVP TTL to be the same as the IP TTL in the innermost IP header. There are many advantages to using a tunneled control plane. GMPLS control messages are encapsulated from being intercepted in the DCN by MPLS/TE capable nodes. Also, this encapsulation may be required for interoperation between a GMPLS/TE and IP/MPLS network. Multiple parallel unnumbered tunnels provide good redundancy properties by having the local and neighbor control plane address independent of the physical interface used for communication. For these reasons, it is RECOMMENDED that all implementations SHOULD support GRE-based tunneled control plane. It is further RECOMMENDED that, for all out- of-band control plane deployments, a tunneled control plane SHOULD be preferred over a native control plane, the tunnel interface preferably be unnumbered and the control plane address SHOULD be the TE Router-ID. 7.4. Separation of Control and Data Plane Traffic PSC-capable nodes implementing an OOB control plane (perhaps to communicate with an optical switch) MUST NOT use the OOB control plane for data traffic. For example, in the case of MPLS service running on top of a GMPLS LSP, if the peer PSC device is reachable via both the control plane and the data plane, control protocols such as LDP MUST NOT form adjacencies over the control plane interfaces. This may be provided by a combination of implementation features and deployment guidelines. For example, implementations MAY use specific Expires July 2005 [Page 15] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 configured interfaces for sending GMPLS control messages irrespective of routing, and these may be deployed such that all routed traffic is routed over the data channel interfaces. Otherwise, control plane interfaces may be configured to not exchange protocol hellos for other protocols. 8. Security Considerations This document does not define new protocols. Consequently, no new security considerations arise. 9. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Expires July 2005 [Page 16] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 11. Acknowledgement The authors would like to thank Adrian Farrell for the helpful discussions and the feedback he gave on the document. 12. Authors' Addresses Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan Email: shiomoto.kohei@lab.ntt.co.jp Rajiv Papneja Isocore Corporation 12359 Sunrise Valley Drive, Suite 100 Reston, Virginia 20191 United States of America Phone: +1-703-860-9273 Email: rpapneja@isocore.com Richard Rabbat Fujitsu Labs of America, Inc. 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085 United States of America Phone: +1-408-530-4537 Email: richard.rabbat@us.fujitsu.com 13. Contributors Yumiko Kawashima NTT Network Service Systems Lab Email: kawashima.yumiko@lab.ntt.co.jp Ashok Narayanan Cisco Systems Email: ashokn@cisco.com Expires July 2005 [Page 17] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 Eiji Oki NTT Network Service Systems Laboratories Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Email: oki.eiji@lab.ntt.co.jp Lyndon Ong Ciena Corporation Email: lyong@ciena.com Vijay Pandian Sycamore Networks Email: Vijay.Pandian@sycamorenet.com Hari Rakotoranto Cisco Systems Email: hrakotor@cisco.com 14. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, IETF RFC 2026, October 1996. [RFC3945] Mannie, E., ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture," RFC 3945, October 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, IETF RFC 2119, March 1997. [RFC3630] Katz, D., Kompella, K. et al., "Traffic Engineering (TE) Extensions to OSPF Version 2," RFC 3630, September 2003. [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)," RFC 3477, January 2003. [RFC2328] Moy, J., "OSPF Version 2," RFC 2328, April 1998. [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments," RFC 1195, December 1990. [RFC3471] Berger, L., ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description," RFC 3471, January 2003. Expires July 2005 [Page 18] draft-shiomoto-ccamp-gmpls-addressing-00 January 2005 [GMPLS-Rtg] K. Kompella, Y. Rekhter (Eds.), "Routing Extensions in Support of Generalized Multi-protocol Label Switching," draft-ietf-ccamp-gmpls-routing-09.txt, October 2003. [GMPLS-OSPF] K. Kompella, Y. Rekhter (Eds.), "OSPF Extensions in Support of Generalized Multi-protocol Label Switching," work in progredraft-ietf-ccamp-gmpls-ospf-gmpls- extensions-12.txt, October 2003. [RFC3209] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. [RFC3473] Berger, L., ed. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions," RFC 3473, January 2003. [EGR-CNT] Berger, L., "GMPLS Signaling Procedure For Egress Control," work in progress, draft-ietf-ccamp-gmpls- egress-control-03.txt, August 2004. [RFC2961] Berger, L., Gan, D., Swallow, G., et al., "RSVP Refresh Overhead Reduction Extensions," RFC 2961, April 2001. [HIERARCHY] Kompella, K. and Rekhter, Y., "LSP Hierarchy with Generalized MPLS TE," work in progress, draft-ietf-mpls- lsp-hierarchy-08.txt, March 2002. [RFC2784] Li, T., Farinacci, D. et al., "Generic Routing Encapsulation (GRE)," RFC 2784, March 2000. Expires July 2005 [Page 19]