doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

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]
+