Network Working Group K. Shiomoto Internet Draft NTT Updates: RFC 3473 R. Papneja Proposed Category: Standards Track Isocore Expires: April 2006 R. Rabbat Fujitsu October 22, 2005 Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks draft-ietf-ccamp-gmpls-addressing-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. 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 This Internet-Draft will expire on April 22, 2006. Abstract This document explains and clarifies the use of addresses in Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim of this document is to facilitate and ensure better interworking of Shiomoto Expires April 22, 2006 [Page 1]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 GMPLS-capable Label Switching Routers (LSRs) based on experience gained in deployments and interoperability testing and proper interpretation of published RFCs. The document recommends a proper approach 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 solutions. Finally, it discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB (Management Information Base) modules. 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Changes from draft-ietf-ccamp-gmpls-addressing-01..............4 3. Terminology....................................................4 4. Support of Numbered and Unnumbered Links.......................6 5. Numbered Addressing............................................6 5.1. Interior Gateway Protocols................................6 5.1.1. Router Address.......................................6 5.1.2. Link ID sub-TLV......................................6 5.1.3. Local Interface IP Address...........................7 5.1.4. Remote Interface IP Address..........................7 5.2. Addresses in RSVP-TE......................................7 5.2.1. IP Tunnel End Point Address in Session Object........7 5.2.2. IP Tunnel Sender Address in Sender Template Object...8 5.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces........8 5.2.4. Explicit Route Object (ERO)..........................8 5.2.5. Record Route Object (RRO)............................9 5.2.6. IP Packet Source Address.............................9 5.2.7. IP Packet Destination Address........................9 6. Unnumbered Addressing.........................................10 6.1. IGP......................................................11 6.1.1. Link Local/Remote Identifiers in OSPF-TE............11 6.1.2. Link Local/Remote Identifiers in IS-IS/TE...........11 6.2. Addresses in RSVP-TE.....................................11 6.2.1. IF_ID RSVP_HOP Object for Unnumbered Interfaces.....12 6.2.2. Explicit Route Object (ERO).........................12 Shiomoto Expires April 22, 2006 [Page 2]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 6.3. Record Route Object (RRO)................................12 6.4. LSP_Tunnel Interface ID Object...........................12 7. RSVP-TE Message Content.......................................12 7.1. ERO and RRO Addresses....................................12 7.1.1. Strict Subobject in ERO.............................13 7.1.2. Loose Subobject in ERO..............................14 7.1.3. RRO.................................................14 7.1.4. Label RRO subobject in RRO..........................15 7.2. Component Link Identification............................16 7.3. Forwarding Destination of Path Message with ERO..........16 8. Topics Related to the GMPLS Control Plane.....................17 8.1. Control Channel Separation...............................17 8.2. Native and Tunneled Control Plane........................17 8.3. Separation of Control and Data Plane Traffic.............17 9. Use of RSVP Hello.............................................18 9.1. Recovery time............................................18 9.2. Dst_Instance Value.......................................18 10. Addresses in the MPLS and GMPLS TE MIB Modules...............18 10.1. Handling IPv6 Source and Destination Addresses..........19 10.1.1. Identifying LSRs...................................19 10.1.2. Configuring GMPLS Tunnels..........................19 10.2. Managing and Monitoring Tunnel Table Entries............20 11. Security Considerations......................................20 12. IANA Considerations..........................................21 13. Acknowledgments..............................................21 14. Contributors.................................................22 15. References...................................................23 15.1. Normative References....................................23 15.2. Informative References..................................24 Authors' Addresses...............................................25 Intellectual Property Statement..................................26 Disclaimer of Validity...........................................26 Copyright Statement..............................................26 Acknowledgment...................................................26 1. Introduction This document explains and clarifies the use of addresses in networks that use GMPLS [RFC3945] as their control plane. GMPLS supports a control entity that is responsible for one or more data plane entities, but 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 Shiomoto Expires April 22, 2006 [Page 3]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 more complex deployment scenarios exist, but these are out of the scope of this document. The document also covers the handling of IPv6 sources and destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB (Management Information Base) modules. Comments are solicited and should be addressed to the working group's mailing list at ccamp@ops.ietf.org and/or the author(s). 2. Changes from draft-ietf-ccamp-gmpls-addressing-01 o Updated section 1 to clarify the scope of this document o REMOVED section 9.3 based on the WG consensus o REMOVED discussion on extended tunnel ID that was in section 5.2.3 o Clarified text in section 4 o Moved unnumbered TE link part from section 5 to 6 and cleaned it o Changed sections 7.1.1 and 7.1.3 to include the bundled link case. o Changed section 7.1.4 to address label recording in RRO. o Reworded confusing text in section 7.2.1. o Added section 9 to address use of RSVP hello o Moved sections related to copyright, IP, etc. around based on new template 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. Shiomoto Expires April 22, 2006 [Page 4]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 o Loopback address: A loopback address is a stable IP address of the advertising router that is always reachable if there is any IP connectivity to it [RFC3630]. Thus, for example, an IPv4 127/24 address is excluded from this definition. o TE Router ID: A stable IP address of an LSR that is always reachable in the control plane if there is any IP connectivity to the LSR, e.g., a loopback address. The most important requirement is that the address does not become unusable if an interface on the LSR is down [RFC3477]. o Router ID: The OSPF protocol version 2 [RFC2328] defines the Router ID to be a 32-bit network unique number assigned to each router running OSPF. IS-IS [RFC1195] includes a similar concept in the System ID. 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 an operator MAY set it to a reachable IP address on the same system. o TE link: "A TE link is a representation in the IS-IS/OSPF Link State advertisements and in the link state database of certain physical resources, and their properties, between two GMPLS nodes." [RFC3945] o Data plane node: A vertex on the TE graph. It is a data plane switch or router. Data plane nodes are connected by TE links which are constructed from physical data links. A data plane node is controlled through some combination of management and control plane actions. A data plane node may be under full or partial control of a control plane node. o Control plane node: A GMPLS protocol speaker. It may be part of a data plane switch or may be a separate computer. Control plane nodes are connected by control channels which are logical connectionless or connection-oriented paths in the control plane. A control plane node is responsible for controlling zero, one or more data plane nodes. o Interface ID: The Interface ID is defined in [RFC3477] and in section 9.1 of [RFC3471]. o TED: Traffic Engineering Database. o LSR: Label Switching Router. o FA: Forwarding Adjacency. Shiomoto Expires April 22, 2006 [Page 5]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 4. Support of Numbered and Unnumbered Links The links in the control plane MAY be numbered or unnumbered. A control plane implementation SHOULD support both numbered and unnumbered control plane links. The links in the data plane MAY be numbered or unnumbered as well. A control plane implementation SHOULD support both numbered and unnumbered data plane links. Addressing for numbered and unnumbered links is described in sections 5 and 6 of this document respectively. 5. Numbered Addressing When numbered addressing is used, addresses are assigned to each node and link in both control and data planes in GMPLS networks. A numbered link is identified by a network unique identifier (e.g., an IP address). 5.1. Interior Gateway Protocols We address in this section numbered addressing using two Interior Gateway Protocols (IGPs) that have extensions defined for GMPLS: OSPF-TE and IS-IS/TE. The routing enhancements for GMPLS are defined in [GMPLS-RTG], [RFC3784], [GMPLS-OSPF] and [GMPLS-ISIS]. 5.1.1. Router Address The Router Address is advertised in OSPF-TE using the Router Address TLV structure of the TE LSA [RFC3630]. In IS-IS/TE, this is referred to as the Traffic Engineering router ID, which is carried in the advertised Traffic Engineering router ID TLV [RFC3784]. The IGP protocols use this as a means to advertise the TE Router ID. 5.1.2. Link ID sub-TLV The Link ID sub-TLV [RFC3630] advertises the Router ID of the remote end of the TE link. For point-to-point links, this is the Router ID of the neighbor. Multi-access links are left for further study. Note that there is no correspondence in IS-IS to the Link ID sub-TLV in OSPF-TE. Instead, IS-IS uses the extended IS reachability TLV Shiomoto Expires April 22, 2006 [Page 6]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 [RFC3784] to carry the System ID, which we have defined in section 3 as the Router ID for the purposes of this document. 5.1.3. Local Interface IP Address The Local Interface IP Address is advertised in: o the Local Interface IP Address sub-TLV in OSPF-TE o the IPv4 Interface Address sub-TLV in IS-IS/TE This is the ID of the local end of the numbered TE link. It MUST be a network unique number. It does not need to be a routable address in the control plane. 5.1.4. Remote Interface IP Address The Remote Interface IP Address is advertised in: o the Remote Interface IP Address sub-TLV in OSPF-TE o the IPv4 Neighbor Address sub-TLV in IS-IS/TE This is the ID of the remote end of the numbered TE link. It MUST be a network unique number. It does not need to be a routable address in the control plane. 5.2. Addresses in RSVP-TE The different subsections describe the use of addresses in the signaling protocol. 5.2.1. IP Tunnel End Point Address in Session Object The IP tunnel end point address of the Session Object [RFC3209] is either an IPv4 or IPv6 address. It is RECOMMENDED that the IP tunnel endpoint address in the Session Object be set to the TE Router ID of the egress since the TE Router ID is a unique routable ID per node. Alternatively, the tunnel end point address MAY be set to the destination data plane address (i.e. the Remote Interface IP Address) if the ingress knows that address. Shiomoto Expires April 22, 2006 [Page 7]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 5.2.2. IP Tunnel Sender Address in Sender Template Object The IP tunnel sender address of the Sender Template Object [RFC3209] is either an IPv4 or IPv6 address. When an LSP is being set up that will not be used to form an FA, it is RECOMMENDED that the IP tunnel sender address in the Sender Template Object specifies the TE Router ID of the ingress LSR since the TE Router ID is a unique, routable ID per node. Alternatively, the tunnel sender address MAY be set to the sender data plane address (i.e. Local Interface IP Address). Note that when an LSP is intended to be used to support a dynamically setup FA, the sender address SHOULD be set to the address that will be assigned to the local end of the TE link (this is a data plane address that will be advertised as the Local Interface IP Address) [MPLS-HIER]. 5.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces There are two addresses used in this object: 1. The IPv4/IPv6 Next/Previous Hop Address: The IPv4/IPv6 Next/Previous Hop Address in the IF ID RSVP HOP Object [RFC3473] in the 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. The IPv4/IPv6 address in the Value Field of the Interface_ID TLV: In both the Path and Resv messages, the IPv4/IPv6 address in the value field of the Interface ID TLV in the IF ID RSVP HOP Object [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. We describe in section 7.2 the case of a bundled link. 5.2.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 7 the choice of addresses in the ERO. Shiomoto Expires April 22, 2006 [Page 8]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 5.2.5. Record Route Object (RRO) 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 also describe in section 7 the choice of addresses in the RRO. 5.2.6. IP Packet Source Address The IP packet source address is either an IPv4 or IPv6 address. The IPv4 or IPv6 source address of the packet that carries the RSVP- TE message MUST be a reachable address of the node sending the RSVP- TE message. It is RECOMMENDED that a stable IPv4 or IPv6 address of the node be used as a source address of the IP packet. In case the source address of the received IP packet containing the Path message is used as the destination address of the Resv message (see section 4.4), setting a stable IPv4 or IPv6 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.2.7. IP Packet Destination Address The IP packet destination address is either an IPv4 or IPv6 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. A Path message is sent to the next hop node. It is RECOMMENDED that a stable IPv4 or IPv6 address of the next hop node be used as the IP destination address of the packet that carries the RSVP-TE message. This address MAY be the TE Router ID of the next hop node or a reachable next-hop (stable) IPv4 or IPv6 address. A Resv message is sent to the previous hop node. It is RECOMMENDED that the IPv4 or IPv6 destination of a Resv message be any of the following: o The IPv4 or IPv6 source address of the received IP packet containing the Path message, o A stable IPv4 or IPv6 address of the previous node (found by consulting the TED and referencing the upstream data plane interface), Shiomoto Expires April 22, 2006 [Page 9]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 o The value in the received PHOP Object field. 6. Unnumbered Addressing In this section, we describe unnumbered addressing as used in GMPLS to refer to different objects and their significance. A TE Router ID is defined to identify the LSR for TE purposes. An unnumbered link is identified by the combination of TE Router ID and a node-unique Interface ID. It is a requirement stated in [RFC3477] that the TE Router ID MUST be a reachable address in the control plane. For unnumbered links, an Explicit Route Object (ERO) signaled as a part of a Label Switched Path (LSP) setup message contains the desired route of an LSP and may include the identifiers for nodes and links specified using TE Router IDs and TE link IDs. Since the LSP setup message must be forwarded within the control plane, each LSR along the path needs to resolve the next hop in the ERO into a control plane address of the LSR (signaling controller) responsible for handling the next hop. Mandating that TE Router ID be a reachable IP address in the control plane simplifies the mapping from ERO hop identifiers to LSR control plane addresses for use as described in section 5.2.7. If a node is identified in the ERO, the TE Router ID used in the ERO can be immediately used to address the control plane message. o If an unnumbered TE link is identified in the ERO, the identifier includes the TE Router ID and can be immediately used to address the control plane message. That is, the TE Router ID is used as the destination for IP packets encapsulating the LSP setup (RSVP Path) message as described in section 5.2.7. o If a numbered TE link is identified in the ERO, the correct control plane address (the TE Router ID) can be found in the IGP advertisement of the identified TE link - the Router Address TLV in the OSPF TE LSA, or the Traffic Engineering router ID TLV in IS-IS (see section 5.1.1). An alternative to using the TE Router ID to identify nodes or unnumbered links in the ERO is to use some other IP-format identifier unique to the data plane address space. In this case some other mechanism is required to allow an LSR to map between data plane identifiers and control plane addresses. Such a mechanism could be provided through configuration or through LMP [GMPLS-LMP]. Shiomoto Expires April 22, 2006 [Page 10]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 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 logical interface. Section 5.1.1 describes how a TE Router ID is advertised. The TE Router ID is used in addition to the node-unique Interface ID to identify an unnumbered link in the data plane. In more complex implementation scenarios where an IGP router advertises TE link information for more than one LSR, the Router ID cannot be used to identify the unnumbered link as it does not uniquely identify the LSR, while on the other hand the TE Router ID uniquely identifies the LSR. 6.1. IGP We address in this section unnumbered addressing using OSPF-TE and IS-IS/TE. 6.1.1. Link Local/Remote Identifiers in OSPF-TE Link Local and Link Remote Identifiers are carried in OSPF using a single sub-TLV of the Link TLV [GMPLS-OSPF]. They advertise the IDs of an unnumbered TE link's local and remote ends respectively. Link Local/Remote Identifiers are numbers unique within the scopes of the advertising LSR and the LSR managing the remote end of the link respectively [RFC3477]. Note that these numbers are not network unique and therefore cannot be used as TE link end addresses on their own. An unnumbered TE link end network-wide identifier is comprised of a TE Router ID associated with the link local end, followed by the link local identifier [RFC3477]. 6.1.2. Link Local/Remote Identifiers in IS-IS/TE The Link Local and Link Remote Identifiers are carried in IS-IS using a single sub-TLV of the extended IS reachability TLV. Link identifiers are exchanged in the Extended Local Circuit ID field of the "Point-to-Point Three-Way Adjacency" IS-IS Option type [GMPLS- ISIS]. The same discussion in 6.1.1 applies here. 6.2. Addresses in RSVP-TE An unnumbered address used for data plane identification consists of the TE Router ID and the associated interface ID. Shiomoto Expires April 22, 2006 [Page 11]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 6.2.1. IF_ID RSVP_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. We describe in section 7.2 the case of a bundled link. 6.2.2. Explicit Route Object (ERO) For unnumbered interfaces in the ERO, the interface ID is either the incoming or outgoing interface of the TE link with respect to the GMPLS-capable LSR. We describe in section 7. the choice of addresses in the ERO. 6.3. Record Route Object (RRO) For unnumbered interfaces in the RRO, the interface ID is either the incoming or outgoing interface of the TE link with respect to the GMPLS-capable LSR. We also describe in section 7. the choice of addresses in the RRO. 6.4. 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 an unnumbered Forward Adjacency Interface ID. The Router ID of the GMPLS-capable LSR MUST be set to the TE Router ID. 7. RSVP-TE Message Content We discuss in this section the addresses used in the RSVP-TE messages, including ERO and RRO addresses as well as component link identification. 7.1. ERO and RRO Addresses We address strict and loose subobjects in ERO separately, then discuss the RRO. Shiomoto Expires April 22, 2006 [Page 12]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 7.1.1. Strict Subobject in ERO Implementations making limited assumptions about the content of an ERO when processing a received Path message may cause interoperability issues. A 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, depending on the level of control required [RFC3209]. In case one subobject is strict, any of the following options are valid: 1. Address or AS number specifying a group of nodes 2. TE Router ID 3. Incoming TE link ID 4. Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects 5. Incoming TE link ID and Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects 6. TE Router ID and Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects 7. Incoming TE link ID, TE Router ID and Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects The label value that identifies a single unidirectional resource between two nodes may be different from the perspective of upstream and downstream nodes. This is typical in the case of fiber switching, because the label value is a number indicating the port/fiber. This is also possible in case of lambda switching, because the label value is a number indicating the lambda, but may not be the value directly indicating the wavelength value (e.g., 1550 nm). Shiomoto Expires April 22, 2006 [Page 13]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 The value of a label in RSVP-TE object 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 ERO subobject MUST include the value of the label for the upstream node's identification of the resource. 7.1.2. Loose Subobject in ERO There are two differences between Loose and Strict subobjects. A subobject marked as a loose hop in an ERO MUST NOT be followed by a subobject indicating a label value [RFC3473]. A subobject marked as a loose hop in an ERO SHOULD never include an identifier (i.e., address or ID) of outgoing interface. There is no way to specify in the 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 a subobject in an ERO is marked as a loose hop and identifies an interface, the subobject SHOULD include the address of the Incoming interface specifying the TE link in the data plane. 7.1.3. RRO When a node adds one or more subobjects to an RRO and sends the Path or the Resv message including the RRO for the purpose of recording the node's addresses used for an LSP, the subobjects (i.e. number, each type, and each content) added by the node SHOULD be the same in the Path RRO and Resv RRO. The intention is that they report the path of the LSP, and that the operator can use the results consistently. At any transit node, it SHOULD be possible to construct the path of the LSP by joining together the RRO from the Path and the Resv messages. It is also important that a whole RRO on a received Resv message can be used as input to an ERO on a Path message. Shiomoto Expires April 22, 2006 [Page 14]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 Therefore, in case that a node adds one or more subobjects to an RRO, any of the following options are valid: 1. TE Router ID 2. Incoming TE link ID 3. Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects 4. Incoming TE link ID and Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects 5. TE Router ID and Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects 6. Incoming TE link ID, TE Router ID and Outgoing TE link ID optionally followed by Component Interface ID subobject and/or one or two Label subobjects An implementation MAY choose any of these options and MUST be prepared to receive an RRO that contains any of these options, but option (4) is RECOMMENDED considering the importance of the record route information to the operator. 7.1.4. Label RRO subobject in RRO Routes and labels can be recorded via the RECORD_ROUTE object (RRO) present in both RSVP Path and Resv messages. When a sender node needs route and label recording, the Label Recording flag is set in the SESSION_ATTRIBUTE object and an RRO is included in the Path message as described in [RFC3209]. As described in [RFC3209] the RRO in a Path message is built up hop by hop and Label Record subobjects SHOULD be included when requested and when the label information is available. Also as described in [RFC3209], for a Resv message "the processing mirrors that of the Path" and "The only difference is that the RRO in a Resv message records the path information in the reverse direction." This means that when Label Record objects are added to the RRO in a Path message they SHOULD also be added to the RRO in the corresponding Resv message. Shiomoto Expires April 22, 2006 [Page 15]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 7.2. Component Link Identification When using a bundled link for a data channel, a component link identifier is specified in the Interface Identification TLV in the IF_ID RSVP_HOP Object in order to fully specify the resource. The Interface Identification TLV is IF_INDEX TLV (Type 3) in the case of an unnumbered component link and IPv4 TLV (Type 1) or IPv6 TLV (Type 2) in the case of a numbered component link. A component link for the upstream data channel may differ from that for the downstream data channel in the case of a bi-directional LSP. In this case, the Interface Identification TLV specifying a downstream interface is followed by another Interface Identification TLV specifying an upstream interface. Note that identifiers in TLVs for upstream and downstream data channels in both sent Path and received Resv messages are specified from the viewpoint of a node sending the Path message and receiving the Resv message, using the identifiers belonging to the node. When a bundled link is used, an LSR constructing an ERO SHOULD include the identifier of the bundled link and MAY choose to not include an identifier of the component link. This is because information about the bundled link is flooded but information about the component links is not. Alternatively, the ERO MAY also include an identifier of a component link if this identifier is known to the LSR that constructs the ERO, and if the LSR wishes to constrain the LSP to a particular component link. Component links MAY be identified within RROs in addition to the bundled link. This might provide useful information for fault diagnosis, and can supply information for the construction of EROs, for example for pinning. 7.3. 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, even if the ERO includes the outgoing interface ID of the Egress node for the Egress control [RFC4003]. Shiomoto Expires April 22, 2006 [Page 16]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 8. Topics Related to the GMPLS Control Plane 8.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 in the data plane may have multiple IP hops between them in the control plane. 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. 8.2. Native and Tunneled Control Plane It is RECOMMENDED that all implementations support a native control plane. If the control plane interface is unnumbered, the RECOMMENDED value for the control plane address is the TE Router-ID. For the case where two adjacent nodes have multiple IP hops between them in the control plane, then as stated in section 9 of [RFC3945], implementations SHOULD use the mechanisms of section 8.1.1 of [MPLS- HIER] whether they use LSP Hierarchy or not. Note that section 8.1.1 of [MPLS-HIER] applies to an "FA-LSP" as stated in that section but also to a "TE link" for the case where a normal TE link is used. Note also that a hop MUST NOT decrement the TTL of the received RSVP- TE message. For a tunneled control plane, the inner RSVP-TE 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-TE TTL to either of the IP TTLs received. Implementations MAY set the RSVP-TE TTL to be the same as the IP TTL in the innermost IP header. 8.3. Separation of Control and Data Plane Traffic Data traffic MUST NOT be transmitted through the control plane. This is crucial when attempting PSC (Packet-Switching Capable) GMPLS with separated control and data channels. Shiomoto Expires April 22, 2006 [Page 17]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 9. Use of RSVP Hello 9.1. Recovery time In a GMPLS network [RFC3473], the handling of control plane communication faults requires the use of RSVP Hello messages that enable RSVP nodes to detect when a neighboring node is not reachable. The Hello messages carry the Restart_Cap object which includes a Recovery Time field. The recovery time indicates the period of time that the restarting node grants to its neighbor to recover state. A value of zero indicates that no state was retained over the restart. The Recovery Time field only has meaning during the restart period. Values of this field received in Hello messages at other times SHOULD be ignored. Further, the Recovery Time field only has meaning on the first Hello message received after restart (which can be determined by examining the source and destination instances in the Hello message as described in [RFC3209] and [RFC3473]). Values of the Recovery Time field received in subsequent Hello messages during the recovery period SHOULD be ignored. If an implementation wishes to abort recovery it SHOULD change the source and destination instances in the Hello message to indicate a discontinuity, and set the Recovery Time to zero. 9.2. Dst_Instance Value During the waiting period for the graceful restart, the Dst_Instance values in all Hello messages MUST be set to zero (0). Therefore, so as to distinguish a non-waiting period from a waiting period, nodes MUST fill in the Dst_Instance field with the Neighbor_Src_instance value most recently received from its neighbor except that received during waiting periods. The procedure applies to verify whether the neighbor determines RSVP communication has been lost and waits for or keeps the RSVP communication. For example, when a node receives from the neighbor the Hello message with the Dst_Instance value set to zero (0) except the neighbor's first hello, it can verify that the neighbor determines RSVP communication has been lost and waits. When the Dst_Instance Value is set to non-zero, it can verify that the neighbor keeps the RSVP communication. 10. Addresses in the MPLS and GMPLS TE MIB Modules This section defines a method of defining or monitoring an LSP tunnel using the MPLS TE MIB module [RFC3812] and GMPLS TE MIB module Shiomoto Expires April 22, 2006 [Page 18]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 [GMPLS-TEMIB] where the ingress and/or egress routers are identified using 128-bit IPv6 addresses. That is, where the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the mplsTunnelTable [RFC3812] cannot be used to carry the tunnel end point address and Extended Tunnel Id fields from the signaled Session Object because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is in use. 10.1. Handling IPv6 Source and Destination Addresses 10.1.1. Identifying LSRs For this feature to be used, all LSRs in the network MUST advertise a 32-bit value that can be used to identify the LSR. In this document, this is referred to as the 32-bit LSR ID. The 32-bit LSR ID is the OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. Note that these are different from TE router ID (See Section 3). The TE router ID is a stable IP address of an LSR that is always reachable while the router ID is a 32-bit network unique number and it is not required to be a reachable IP address. 10.1.2. Configuring GMPLS Tunnels When setting up RSVP TE tunnels, it is common practice to copy the values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel ID and IPv4 tunnel end point address fields, respectively, in the RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209]. This approach cannot be used when the ingress and egress routers are identified by 128-bit IPv6 addresses as the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields are defined to be 32-bit values [RFC3811] and [RFC3812]. Instead, the IPv6 addresses SHOULD be configured in the mplsHopTable as the first and last hops of the mplsTunnelHopTable entries defining the explicit route for the tunnel. Note that this implies that a tunnel with IPv6 source and destination addresses MUST have an explicit route configured, although it should be noted that the configuration of an explicit route in this way does not imply that an explicit route will be signaled. In more detail, the tunnel is configured at the ingress router as follows. See [RFC3812] for definitions of MIB table objects and for default (that is, "normal") behavior. The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. Shiomoto Expires April 22, 2006 [Page 19]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields SHOULD be set to 32-bit LSR IDs for ingress and egress LSR respectively. The mplsTunnelHopTableIndex MUST be set to a non-zero value. That is, an explicit route MUST be specified. The first hop of the explicit route MUST have mplsTunnelHopAddrType field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the ingress router that is reachable in the control plane. The last hop of the explicit route MUST have mplsTunnelHopAddrType field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the egress router that is reachable in the control plane. The ingress router SHOULD set the signaled values of the Extended Tunnel ID and IPv6 tunnel end point address fields, respectively, of the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [RFC3209] from the mplsTunnelHopIpAddr object of the first and last hops in the configured explicit route. 10.2. Managing and Monitoring Tunnel Table Entries The TE MIB module may be used for managing and monitoring MPLS and GMPLS TE LSPs, as well as configuring them as described in section 8.2. This function is particularly important at egress and transit LSRs. For a tunnel with IPv6 source and destination addresses, an LSR implementation SHOULD return values in the mplsTunnelTable as follows (where "normal" behavior is the default taken from [RFC3812]). The mplsTunnelIndex and mplsTunnelInstance fields are set as normal. The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to 32-bit LSR IDs. That is, each transit and egress router maps from the IPv6 address in the Extended Tunnel ID field to the 32-bit LSR ID of the ingress LSR. Each transit router also maps from the IPv6 address in the IPv6 tunnel end point address field to the 32-bit LSR ID of the egress LSR. 11. Security Considerations In the interoperability testing we conducted, the major issue we found was the use of control channels for forwarding data. This was Shiomoto Expires April 22, 2006 [Page 20]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 due to the setting of both control and data plane addresses to the same value in PSC (Packet-Switching Capable) equipment. This occurred when attempting to test PSC GMPLS with separated control and data channels. What resulted instead were parallel interfaces with the same addresses. This could be avoided simply by keeping the addresses for the control and data plane separate. 12. IANA Considerations This document defines no new code points and requires no action from IANA. 13. Acknowledgments The authors would like to thank Adrian Farrel for the helpful discussions and the feedback he gave on the document. In addition, Arthi Ayyangar, Deborah Brungard, Diego Caviglia, Dimitri Papadimitriou, Jonathan Sadler, Hidetsugu Sugiyama provided helpful comments and suggestions. Shiomoto Expires April 22, 2006 [Page 21]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 14. Contributors Alan Davey Data Connection Ltd Phone: +44 20 8366 1177 Email: Alan.Davey@dataconnection.com Yumiko Kawashima NTT Network Service Systems Lab Email: kawashima.yumiko@lab.ntt.co.jp Kaori Shimizu NTT Network Service Systems Lab Email: shimizu.kaori@lab.ntt.co.jp Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Ashok Narayanan Cisco Systems, Inc. Email: ashokn@cisco.com 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 Shiomoto Expires April 22, 2006 [Page 22]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 Email: lyong@ciena.com Vijay Pandian Sycamore Networks Email: Vijay.Pandian@sycamorenet.com Hari Rakotoranto Cisco Systems Email: hrakotor@cisco.com 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004. Shiomoto Expires April 22, 2006 [Page 23]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004. [RFC3811] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005. [GMPLS-OSPF] Kompella, K. and Y. Rekhter (Eds.), "OSPF Extensions in Support of Generalized Multi-protocol Label Switching," work in progress, draft-ietf-ccamp-ospf-gmpls-extensions- 12.txt, October 2003. [GMPLS-RTG] Kompella, K. and Y. Rekhter (Eds.), "Routing Extensions in Support of Generalized Multi-protocol Label Switching," work in progress, draft-ietf-ccamp-gmpls-routing-09.txt, October 2003. [GMPLS-TEMIB] Nadeau, T. and A. Farrel (Eds.), "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base," work in progress, draft-ietf- ccamp-gmpls-te-mib-09.txt, June 2005. [MPLS-HIER] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE," work in progress, draft-ietf-mpls- lsp-hierarchy-08.txt, March 2002. 15.2. Informative References [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. Shiomoto Expires April 22, 2006 [Page 24]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [GMPLS-ISIS] Kompella, K. and Y. Rekhter (Eds.), "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching," work in progress, draft-ietf-isis-gmpls-extensions-19.txt, October 2003. [GMPLS-LMP] Lang, J. (Ed.), "Link Management Protocol (LMP)," work in progress, draft-ietf-ccamp-lmp-10.txt, October 2003. Authors' Addresses Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori Musashino, Tokyo 180-8585 Japan Phone: +81 422 59 4402 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 Laboratories of America 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085 United States of America Phone: +1 408-530-4537 Email: richard@us.fujitsu.com Shiomoto Expires April 22, 2006 [Page 25]
Internet-Draft Use of Addresses in GMPLS Networks October 2005 Intellectual Property Statement 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 procedures with respect to rights in RFC 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. 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shiomoto Expires April 22, 2006 [Page 26]
