path: root/doc/rfc/rfc4990.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L