From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4990.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc4990.txt (limited to 'doc/rfc/rfc4990.txt') diff --git a/doc/rfc/rfc4990.txt b/doc/rfc/rfc4990.txt new file mode 100644 index 0000000..d9dd3a8 --- /dev/null +++ b/doc/rfc/rfc4990.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group K. Shiomoto +Request for Comments: 4990 NTT +Category: Informational R. Papneja + Isocore + R. Rabbat + Google + September 2007 + + + Use of Addresses + in Generalized Multiprotocol Label Switching (GMPLS) Networks + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This document clarifies the use of addresses in Generalized + Multiprotocol Label Switching (GMPLS) networks. The aim is to + facilitate interworking of GMPLS-capable Label Switching Routers + (LSRs). The document is based on experience gained in + implementation, interoperability testing, and deployment. + + The document describes how to interpret address and identifier fields + within GMPLS protocols, and how to choose which addresses to set in + those fields for specific control plane usage models. It also + discusses how to handle IPv6 sources and destinations in the MPLS and + GMPLS Traffic Engineering (TE) Management Information Base (MIB) + modules. + + This document does not define new procedures or processes. Whenever + this document makes requirements statements or recommendations, these + are taken from normative text in the referenced RFCs. + + + + + + + + + + + + + + + +Shiomoto, et al. Informational [Page 1] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 3. Support of Numbered and Unnumbered Links ........................5 + 4. Numbered Addressing .............................................6 + 4.1. Numbered Addresses in IGPs .................................6 + 4.1.1. Router Address and TE Router ID .....................6 + 4.1.2. Link ID and Remote Router ID ........................6 + 4.1.3. Local Interface IP Address ..........................7 + 4.1.4. Remote Interface IP Address .........................7 + 4.2. Numbered Addresses in RSVP-TE ..............................7 + 4.2.1. IP Tunnel End Point Address in Session Object .......7 + 4.2.2. IP Tunnel Sender Address in Sender Template Object ..8 + 4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces .......8 + 4.2.4. Explicit Route Object (ERO) .........................9 + 4.2.5. Record Route Object (RRO) ...........................9 + 4.2.6. IP Packet Source Address ............................9 + 4.2.7. IP Packet Destination Address .......................9 + 5. Unnumbered Addressing ..........................................10 + 5.1. Unnumbered Addresses in IGPs ..............................10 + 5.1.1. Link Local/Remote Identifiers in OSPF-TE ...........10 + 5.1.2. Link Local/Remote Identifiers in IS-IS-TE ..........11 + 5.2. Unnumbered Addresses in RSVP-TE ...........................11 + 5.2.1. Sender and End Point Addresses .....................11 + 5.2.2. IF_ID RSVP_HOP Object for Unnumbered Interfaces ....11 + 5.2.3. Explicit Route Object (ERO) ........................11 + 5.2.4. Record Route Object (RRO) ..........................11 + 5.2.5. LSP_Tunnel Interface ID Object .....................12 + 5.2.6. IP Packet Addresses ................................12 + 6. RSVP-TE Message Content ........................................12 + 6.1. ERO and RRO Addresses .....................................12 + 6.1.1. Strict Subobject in ERO ............................12 + 6.1.2. Loose Subobject in ERO .............................14 + 6.1.3. RRO ................................................14 + 6.1.4. Label Record Subobject in RRO ......................15 + 6.2. Component Link Identification .............................15 + 6.3. Forwarding Destination of Path Messages with ERO ..........16 + 7. Topics Related to the GMPLS Control Plane ......................16 + 7.1. Control Channel Separation ................................16 + 7.1.1. Native and Tunneled Control Plane ..................16 + 7.2. Separation of Control and Data Plane Traffic ..............17 + 8. Addresses in the MPLS and GMPLS TE MIB Modules .................17 + 8.1. Handling IPv6 Source and Destination Addresses ............18 + 8.1.1. Identifying LSRs ...................................18 + 8.1.2. Configuring GMPLS Tunnels ..........................18 + 8.2. Managing and Monitoring Tunnel Table Entries ..............19 + 9. Security Considerations ........................................19 + + + +Shiomoto, et al. Informational [Page 2] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + 10. Acknowledgments ...............................................20 + 11. References ....................................................20 + 11.1. Normative References .....................................20 + 11.2. Informative References ...................................21 + +1. Introduction + + This informational document clarifies the use of addresses in + Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] networks. + The aim is to facilitate interworking of GMPLS-capable Label + Switching Routers (LSRs). The document is based on experience gained + in implementation, interoperability testing, and deployment. + + The document describes how to interpret address and identifier fields + within GMPLS protocols (RSVP-TE [RFC3473], GMPLS OSPF [RFC4203], and + GMPLS ISIS [RFC4205]), and how to choose which addresses to set in + those fields for specific control plane usage models. + + This document does not define new procedures or processes and the + protocol specifications listed above should be treated as definitive. + Furthermore, where this document makes requirements statements or + recommendations, these are taken from normative text in the + referenced RFCs. Nothing in this document should be considered + normative. + + This document also discusses how to handle IPv6 sources and + destinations in the MPLS and GMPLS Traffic Engineering (TE) + Management Information Base (MIB) modules [RFC3812], [RFC4802]. + +2. Terminology + + As described in [RFC3945], the components of a GMPLS network may be + separated into a data plane and a control plane. The control plane + may be further split into signaling components and routing + components. + + A data plane switch or router is called a data plane entity. It is a + node on the data plane topology graph. A data plane resource is a + facility available in the data plane, such as a data plane entity + (node), data link (edge), or data label (such as a lambda). + + In the control plane, there are protocol speakers that are software + implementations that communicate using signaling or routing + protocols. These are control plane entities, and may be physically + located separately from the data plane entities that they control. + Further, there may be separate routing entities and signaling + entities. + + + + +Shiomoto, et al. Informational [Page 3] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + GMPLS supports a control plane entity that is responsible for one or + more data plane entities, and supports the separation of signaling + and routing control plane entities. 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 entity responsible for + participating in the GMPLS signaling and routing 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). + + Note that the term 'Router ID' is used in two contexts within GMPLS. + It may refer to an identifier of 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. + + 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 [RFC3477], [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], [RFC3630]. + + 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 node. + + 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 that + + + +Shiomoto, et al. Informational [Page 4] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + 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 that are logical + connection-less 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 Data Plane Address: This document refers to a data plane address + in the context of GMPLS. It does not refer to addresses such as + E.164 SAPI in Synchronous Digital Hierarchy (SDH). + + o Control Plane Address: An address used to identify a control plane + resource including, and restricted to, control plane nodes and + control channels. + + o IP Time to Live (TTL): The IPv4 TTL field or the IPv6 Hop Limit + field, whichever is applicable. + + o TED: Traffic Engineering Database. + + o LSR: Label Switching Router. + + o FA: Forwarding Adjacency. + + o IGP: Interior Gateway Protocol. + +3. Support of Numbered and Unnumbered Links + + The links in the control and data planes may be numbered or + unnumbered [RFC3945]. That is, their end points may be assigned IP + addresses, or may be assigned link IDs specific to the control plane + or data plane entity at the end of the link. Implementations may + decide to support numbered and/or unnumbered addressing. + + The argument for numbered addressing is that it simplifies + troubleshooting. The argument for unnumbered addressing is to save + on IP address resources. + + An LSR may choose to only support its own links being configured as + numbered, or may only support its own links being configured as + + + +Shiomoto, et al. Informational [Page 5] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + unnumbered. But an LSR must not restrict the choice of other LSRs to + use numbered or unnumbered links since this might lead to + interoperablity issues. Thus, a node should be able to accept and + process link advertisements containing both numbered and unnumbered + addresses. + + Numbered and unnumbered addressing is described in Sections 4 and 5 + of this document, respectively. + +4. Numbered Addressing + + When numbered addressing is used, addresses are assigned to each node + and link in both the control and data planes of the GMPLS network. + + A numbered link is identified by a network-unique identifier (e.g., + an IP address). + +4.1. Numbered Addresses in IGPs + + In this section, we discuss 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 [RFC3630], [RFC3784], [RFC4202], [RFC4203], and [RFC4205]. + +4.1.1. Router Address and TE Router ID + + The IGPs define a field called the "Router Address". It is used to + advertise the TE Router ID. + + The Router Address is advertised in OSPF-TE using the Router Address + TLV structure of the TE Link State Advertisement (LSA) [RFC3630]. + + In IS-IS-TE, this is referred to as the Traffic Engineering router + ID, and is carried in the advertised Traffic Engineering router ID + TLV [RFC3784]. + +4.1.2. Link ID and Remote Router ID + + In OSPF-TE [RFC3630], the Router ID of the remote end of a TE link is + carried in the Link ID sub-TLV. This applies for point-to-point TE + links only; multi-access links are for further study. + + In IS-IS-TE [RFC3784], the Extended IS Reachability TLV is used to + carry the System ID. This corresponds to the Router ID as described + in Section 2. + + + + + + +Shiomoto, et al. Informational [Page 6] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + +4.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 [RFC3630] + + o the IPv4 Interface Address sub-TLV in IS-IS-TE [RFC3784]. + + This is the ID of the local end of the numbered TE link. It must be + a network-unique number (since this section is devoted to numbered + addressing), but it does not need to be a routable address in the + control plane. + +4.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 [RFC3630] + + o the IPv4 Neighbor Address sub-TLV in IS-IS-TE [RFC3784]. + + This is the ID of the remote end of the numbered TE link. It must be + a network-unique number (since this section is devoted to numbered + addressing), but it does not need to be a routable address in the + control plane + +4.2. Numbered Addresses in RSVP-TE + + The following subsections describe the use of addresses in the GMPLS + signaling protocol [RFC3209], [RFC3473]. + +4.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. + + The Session Object is invariant for all messages relating to the same + Label Switched Path (LSP). The initiator of a Path message sets the + IP tunnel end point address in the Session Object to one of: + + o The TE Router ID of the egress since the TE Router ID is routable + and uniquely identifies the egress node. + + o The destination data plane address to precisely identify the + interface that should be used for the final hop of the LSP. That + is, the Remote Interface IP Address of the final TE link, if the + ingress knows that address. + + + + +Shiomoto, et al. Informational [Page 7] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + The IP tunnel end point address in the Session Object is not required + to be routable in the control plane, but should be present in the + TED. + +4.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 to support an IPv4-numbered FA, [RFC4206] + recommends that the IP tunnel sender address be set to the head-end + address of the TE link that is to be created so that the tail-end + address can be inferred as the /31 partner address. + + When an LSP is being set up that will not be used to form an FA, the + IP tunnel sender address in the Sender Template Object may be set to + one of: + + o The TE Router ID of the ingress LSR since the TE Router ID is a + unique, routable ID per node. + + o The sender data plane address (i.e., the Local Interface IP + Address). + +4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces + + There are two addresses used in the IF_ID RSVP_HOP object. + + 1. The IPv4/IPv6 Next/Previous Hop Address [RFC3473] + + When used in a Path or Resv messages, this address specifies the + IP reachable address of the control plane interface used to send + the messages, or the TE Router ID of the node that sends the + message. That is, it is a routable control plane address of the + sender of the message and can be used to send return messages. + Note that because of data plane / control plane separation (see + Section 7.1) and data plane robustness in the face of control + plane faults, it may be advisable to use the TE Router ID since it + is a more stable address. + + 2. The IPv4/IPv6 address in the Value Field of the Interface_ID TLV + [RFC3471] + + This address identifies the data channel associated with the + signaling message. In all cases, the data channel is indicated by + the use of the data plane local interface address at the upstream + LSR, that is, at the sender of the Path message. + + + + +Shiomoto, et al. Informational [Page 8] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + See Section 6.2 for a description of these fields when bundled links + are used. + +4.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. + + See Section 6 for a description of the use of addresses in the ERO. + +4.2.5. Record Route Object (RRO) + + The IPv4/IPv6 address in the RRO provides a data-plane identifier of + either a TE node or a TE link that is part of an LSP that has been + established or is being established. + + See Section 6 for a description of the use of addresses in the RRO. + +4.2.6. IP Packet Source Address + + GMPLS signaling messages are encapsulated in IP. The IP packet + source address is either an IPv4 or IPv6 address and must be a + reachable control plane address of the node sending the TE message. + In order to provide control plane robustness, a stable IPv4 or IPv6 + control plane address (for example, the TE Router ID) can be used. + + Some implementations may use the IP source address of a received IP + packet containing a Path message as the destination IP address of a + packet containing the corresponding Resv message (see Section 4.2.7). + Using a stable IPv4 or IPv6 address in the IP packet containing the + Path message supports this situation robustly when one of the control + plane interfaces is down. + +4.2.7. IP Packet Destination Address + + The IP packet destination address for an IP packet carrying a GMPLS + signaling message is either an IPv4 or IPv6 address, and must be + reachable in the control plane if the message is to be delivered. It + must be an address of the intended next-hop recipient of the message. + That is, unlike RSVP, the IP packet is not addressed to the ultimate + destination (the egress). + + For a Path message, a stable IPv4 or IPv6 address of the next-hop + node may be used. This may be the TE Router ID of the next-hop node. + A suitable address may be determined by examining the TE + advertisements for the TE link that will form the next-hop data link. + + + + + +Shiomoto, et al. Informational [Page 9] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + A Resv message is sent to the previous-hop node. The IPv4 or IPv6 + destination of an IP packet carrying a Resv message may 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 + examining the TE advertisements for the upstream data plane + interface. + + o The value in the received in the Next/Previous Hop Address field + of the RSVP_HOP (PHOP) Object [RFC2205]. + +5. Unnumbered Addressing + + An unnumbered address is the combination of a network-unique node + identifier and a node-unique interface identifier. + + An unnumbered link is identified by the combination of the TE Router + ID that is a reachable address in the control plane and a node-unique + Interface ID [RFC3477]. + +5.1. Unnumbered Addresses in IGPs + + In this section, we consider unnumbered address advertisement using + OSPF-TE and IS-IS-TE. + +5.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 [RFC4203]. 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 identifiers on their own. An unnumbered TE + link end network-wide identifier is comprised of two elements as + defined in [RFC3477]: + + - A TE Router ID that is associated with the link local end + + - The link local identifier. + + + + + + +Shiomoto, et al. Informational [Page 10] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + +5.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 [RFC4205]. + + The same discussion of unique identification applies here as in + Section 5.1.1. + +5.2. Unnumbered Addresses in RSVP-TE + + We consider in this section the interface ID fields of objects used + in RSVP-TE in the case of unnumbered addressing. + +5.2.1. Sender and End Point Addresses + + The IP Tunnel End Point Address in the RSVP Session Object and the IP + Tunnel Sender Address in the RSVP Sender Template Object cannot use + unnumbered addresses [RFC3209], [RFC3473]. + +5.2.2. 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 an unnumbered interface. + + In both Path and Resv messages, the value of the interface ID in the + IF_INDEX TLV specifies the local interface ID of the associated data + channel at the upstream node (the node sending the Path message and + receiving the Resv message). + + See Section 6.2 for a description of the use bundled links. + +5.2.3. Explicit Route Object (ERO) + + The ERO may use an unnumbered identifier of a TE link to be part of + the signaled LSP. + + See Section 6 for a description of the use of addresses in the ERO. + +5.2.4. Record Route Object (RRO) + + The RRO records the data-plane identifiers of TE nodes and TE links + that are part of an LSP that has been established or is being + established. TE links may be identified using unnumbered addressing. + + See Section 6 for a description of the use of addresses in the RRO. + + + + +Shiomoto, et al. Informational [Page 11] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + +5.2.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 an unnumbered + Forward Adjacency Interface ID. The Router ID of the GMPLS-capable + LSR must be set to the TE Router ID. + +5.2.6. IP Packet Addresses + + IP packets can only be addressed to numbered addresses. + +6. RSVP-TE Message Content + + This section examines the use of addresses in RSVP EROs and RROs, the + identification of component links, and forwarding addresses for RSVP + messages. + +6.1. ERO and RRO Addresses + + EROs may contain strict or loose hop subobjects. These are discussed + separately below. A separate section describes the use of addresses + in the RRO. + + Implementations making limited assumptions about the content of an + ERO or RRO when processing a received RSVP message may cause or + experience interoperability issues. Therefore, implementations that + want to ensure full interoperability need to support the receipt for + processing of all ERO and RRO options applicable to their hardware + capabilities. + + Note that the phrase "receipt for processing" is intended to indicate + that an LSR is not expected to look ahead in an ERO or process any + subobjects that do not refer to the LSR itself or to the next hop in + the ERO. An LSR is not generally expected to process an RRO except + by adding its own information. + + Note also that implementations do not need to support the ERO options + containing Component Link IDs if they do not support link bundling + [RFC4201]. + + ERO processing at region boundaries is described in [RFC4206]. + +6.1.1. Strict Subobject in ERO + + Depending on the level of control required, a subobject in the ERO + includes an address that may specify 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 [RFC3209]. + + + +Shiomoto, et al. Informational [Page 12] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + A hop may be flagged as strict (meaning that the LSP must go directly + to the identified next hop without any intervening nodes), or loose. + + If a hop is strict, the ERO may contain any of the following. + + 1. Address prefix or AS number specifying a group of nodes. + + 2. TE Router ID identifying a specific node. + + 3. Link ID identifying an incoming TE link. + + 4. Link ID identifying an outgoing TE link, optionally followed by a + Component Interface ID and/or one or two Labels. + + 5. Link ID identifying an incoming TE link, followed by a Link ID + identifying an outgoing TE link, optionally followed by a + Component Interface ID and/or one or two Labels. + + 6. TE Router ID identifying a specific node, followed by a Link ID + identifying an outgoing TE link, optionally followed by a + Component Interface ID and/or one or two Labels. + + 7. Link ID identifying an incoming TE link, followed by a TE Router + ID identifying a specific node, followed by a Link ID identifying + an outgoing TE link, optionally followed by Component Interface ID + and/or one or two Labels. + + 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 typically the case in fiber switching + because the label value is a number indicating the port/fiber. It + may also be the case for lambda switching, because the label value is + an index for the lambda in the hardware and may not be a globally + defined value such as the wavelength in nanometers. + + The value of a label in any RSVP-TE object indicates the value from + the perspective of the sender of the object/TLV [RFC3471]. + Therefore, any label in an ERO is given using the upstream node's + identification of the resource. + + + + + + + + + + + + +Shiomoto, et al. Informational [Page 13] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + +6.1.2. Loose Subobject in ERO + + There are two differences between Loose and Strict subobjects. + + o A subobject marked as a loose hop in an ERO must not be followed + by a subobject indicating a label value [RFC3473]. + + o A subobject marked as a loose hop in an ERO should never include + an identifier (i.e., address or ID) of the outgoing interface. + + There is no way to specify in an ERO whether a subobject identifies + an incoming or outgoing TE link. Path computation must be performed + by an LSR when it encounters a loose hop in order to resolve the LSP + route to the identified next hop. If an interface is specified as a + loose hop and is treated as an incoming interface, the path + computation will select a path that enters an LSR through that + interface. If the interface was intended to be used as an outgoing + interface, the computed path may be unsatisfactory and the explicit + route in the ERO may be impossible to resolve. Thus a loose hop that + identifies an interface should always identify the incoming TE link + in the data plane. + +6.1.3. RRO + + The RRO is used on Path and Resv messages to record the path of an + LSP. Each LSR adds subobjects to the RRO to record information. The + information added to an RRO by a node should be the same in the Path + and the Resv message although there may be some information that is + not available during LSP setup. + + One use of the RRO is to allow the operator to view the path of the + LSP. 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 Resv message received at + an ingress LSR can be used as an ERO on a subsequent Path message to + completely recreate the LSP. + + Therefore, when a node adds one or more subobjects to an RRO, any of + the following options is valid. + + 1. TE Router ID identifying the LSR. + + 2. Link ID identifying the incoming (upstream) TE link. + + 3. Link ID identifying the outgoing (downstream) TE link, optionally + followed by a Component Interface ID and/or one or two Labels. + + + +Shiomoto, et al. Informational [Page 14] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + 4. Link ID identifying the incoming (upstream) TE link, followed by a + Link ID identifying the outgoing (downstream) TE link, optionally + followed by a Component Interface ID and/or one or two Labels. + + 5. TE Router ID identifying the LSR, followed by a Link ID + identifying the outgoing (downstream) TE link, optionally followed + by a Component Interface ID and/or one or two Labels. + + 6. Link ID identifying the incoming (upstream) TE link, followed by + the TE Router ID identifying the LSR, followed by a Link ID + identifying the outgoing (downstream) TE link, optionally followed + by a Component Interface ID and/or one or two Labels. + + An implementation may choose any of these options and must be + prepared to receive an RRO that contains any of these options. + +6.1.4. Label Record Subobject in RRO + + RRO Label recording is requested by an ingress node setting the Label + Recording flag in the SESSION_ATTRIBUTE object and including an RRO + is included in the Path message as described in [RFC3209]. Under + these circumstances, each LSR along the LSP should include label + information in the RRO in the Path message if it is available. + + As described in [RFC3209], the processing for a Resv message "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 hops are added to the RRO in the reverse order, but the + information added at each LSR is in the same order (see Sections + 6.1.1, 6.1.2, and 6.1.3). Thus, when label recording is requested, + labels are included in the RROs in both the Path and Resv messages. + +6.2. Component Link Identification + + When a bundled link [RFC4201] is used to provide a data channel, a + component link identifier is specified in the Interface + Identification TLV in the IF_ID RSVP_HOP Object in order to indicate + which data channel from within the bundle is to be used. 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. + + The component link for the upstream data channel may differ from that + for the downstream data channel in the case of a bidirectional LSP. + In this case, the Interface Identification TLV specifying a + downstream interface is followed by another Interface Identification + TLV specifying an upstream interface. + + + + +Shiomoto, et al. Informational [Page 15] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + Note that identifiers in TLVs for upstream and downstream data + channels in both Path and Resv messages are specified from the + viewpoint of the upstream node (the node sending the Path message and + receiving the Resv message), using identifiers belonging to the node. + + An LSR constructing an ERO may include a Link ID that identifies a + bundled link. If the LSR knows the identities of the component links + and wishes to exert control, it may also include component link + identifiers in the ERO. Otherwise, the component link identifiers + are not included in the ERO. + + When a bundled link is in use, the RRO may include the Link ID that + identifies the link bundle. Additionally, the RRO may include a + component link identifier. + +6.3. Forwarding Destination of Path Messages 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 Egress control [RFC4003]. + +7. Topics Related to the 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 nodes that are adjacent 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. + +7.1.1. Native and Tunneled Control Plane + + A native control plane uses IP forwarding to deliver RSVP-TE messages + between protocol speakers. The message is not further encapsulated. + + IP forwarding applies normal rules to the IP header. Note that an IP + hop must not decrement the TTL of the received RSVP-TE message. + + 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], + + + +Shiomoto, et al. Informational [Page 16] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + implementations should use the mechanisms of Section 6.1.1 of + [RFC4206] whether or not they use LSP Hierarchy. Note that Section + 6.1.1 of [RFC4206] 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. + + With a tunneled control plane, the RSVP-TE message is packaged in an + IP packet that is inserted into a tunnel such that the IP packet will + traverse exactly one IP hop. Various tunneling techniques can be + used including (but not limited to) IP-in-IP, Generic Routing + Encapsulation (GRE), and IP in MPLS. + + Where the tunneling mechanism includes a TTL, it should be treated 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 any other TTL (whether the IP TTL or the tunnel + TTL). + + It has been observed that some implementations do not support the + tunneled control plane features, and it is suggested that to enable + interoperability, all implementations should support at least a + native control plane. + +7.2. 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. + +8. Addresses in the MPLS and GMPLS TE MIB Modules + + This section describes a method of defining or monitoring an LSP + tunnel using the MPLS-TE-STD-MIB module [RFC3812] and GMPLS-TE-STD- + MIB module [RFC4802] where the ingress and/or egress routers are + identified using 128-bit IPv6 addresses. This is the case when 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. + + The normative text for MIB objects for control and monitoring MPLS + and GMPLS nodes is found in the RFCs referenced above. This section + makes no changes to those objects, but describes how they may be used + to provide the necessary function. + + + + + + + +Shiomoto, et al. Informational [Page 17] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + +8.1. Handling IPv6 Source and Destination Addresses + +8.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 2). + +8.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], [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. + + The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields should be + set to 32-bit LSR IDs for ingress and egress LSRs, 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. + + + + +Shiomoto, et al. Informational [Page 18] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + 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. + +8.2. Managing and Monitoring Tunnel Table Entries + + In addition to their use for configuring LSPs as described in Section + 8.1, the TE MIB modules (MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB) may be + used for managing and monitoring MPLS and GMPLS TE LSPs, + respectively. 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. + +9. Security Considerations + + In the interoperability testing we conducted, the major issue we + found was the use of control channels for forwarding data. This was + 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. + + + + + + + + +Shiomoto, et al. Informational [Page 19] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + +10. Acknowledgments + + The following people made textual contributions to this document: + + Alan Davey, Yumiko Kawashima, Kaori Shimizu, Thomas D. Nadeau, + Ashok Narayanan, Eiji Oki, Lyndon Ong, Vijay Pandian, Hari + Rakotoranto, and Adrian Farrel. + + The authors would like to thank Adrian Farrel for the helpful + discussions and the feedback he gave on the document. In addition, + Jari Arkko, Arthi Ayyangar, Deborah Brungard, Diego Caviglia, Lisa + Dusseault, Dimitri Papadimitriou, Jonathan Sadler, Hidetsugu + Sugiyama, and Julien Meuric provided helpful comments and + suggestions. + + Adrian Farrel edited the final revisions of this document before and + after working group last call. + +11. References + +11.1. Normative References + + [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 + Functional Specification", RFC 2205, September 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., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Functional Description", RFC + 3471, January 2003. + + [RFC3473] Berger, L., Ed., "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. + + + +Shiomoto, et al. Informational [Page 20] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + [RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of + Textual Conventions (TCs) for Multiprotocol Label Switching + (MPLS) Management", RFC 3811, June 2004. + + [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., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture", RFC 3945, October 2004. + + [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", + RFC 4003, February 2005. + + [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in + MPLS Traffic Engineering (TE)", RFC 4201, October 2005. + + [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4202, October 2005. + + [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in + Support of Generalized Multi-protocol Label Switching", RFC + 4203, October 2005. + + [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with + Generalized MPLS TE", RFC 4206, October 2005. + +11.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. + + [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate + System (IS-IS) Extensions for Traffic Engineering (TE)", + RFC 3784, June 2004. + + [RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate + System to Intermediate System (IS-IS) Extensions in Support + of Generalized Multi-Protocol Label Switching (GMPLS)", RFC + 4205, October 2005. + + + + + + +Shiomoto, et al. Informational [Page 21] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + + [RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized + Multiprotocol Label Switching (GMPLS) Traffic Engineering + Management Information Base", RFC 4802, February 2007. + +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 + + + Richard Rabbat + Google Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + + Phone: +1 650-714-7618 + EMail: rabbat@alum.mit.edu + + + 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 + + + + + + + + + + + + + + + + + + +Shiomoto, et al. Informational [Page 22] + +RFC 4990 Use of Addresses in GMPLS Networks September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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. + +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 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. + + + + + + + + + + + + +Shiomoto, et al. Informational [Page 23] + -- cgit v1.2.3