[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-shiomoto-ccamp-gmpls-addressing) 00 01 02 03 04 05 06 07 08 RFC 4990

Network Working Group                               Kohei Shiomoto (NTT)
Internet Draft                                   Rajiv Papneja (ISOCORE)
Updates: 3473                                   Richard Rabbat (Fujitsu)
Proposed Category: Standards Track
Expires: December 2005                                         June 2005

      Use of Addresses in Generalized Multi-Protocol Label Switching
                             (GMPLS) Networks

                 draft-ietf-ccamp-gmpls-addressing-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document explains and clarifies the use of addresses in
   Generalized Multi-Protocol Label Switching (GMPLS) networks.  The aim
   of this document is to facilitate and ensure better interworking of
   GMPLS-capable Label Switching Routers (LSRs) based on experience
   gained in deployments and interoperability testing and proper
   interpretation of published RFCs.

   The document recommends a proper approach for the interpretation and
   choice of address and identifier fields within GMPLS protocols and
   references specific control plane usage models.  It also examines
   some common GMPLS Resource Reservation Protocol-Traffic Engineering
   (RSVP-TE) signaling message processing issues and recommends

                        Expires December 2005                   [Page 1]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   solutions.  It finally discusses how to handle IPv6 sources and
   destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB
   (Management Information Base) modules.


Table of Contents

   1. Introduction.................................................... 3
   2. Conventions Used in This Document............................... 4
   3. Terminology..................................................... 4
   4. Addressing in GMPLS Networks.................................... 5
   5. Numbered Addressing............................................. 5
   5.1. Interior Gateway Protocols.................................... 6
   5.1.1. Router Address.............................................. 6
   5.1.2. Link ID sub-TLV............................................. 7
   5.1.3. Local Interface IP Address.................................. 7
   5.1.4. Remote Interface IP Address................................. 7
   5.2. Use of Addresses in RSVP-TE................................... 7
   5.2.1. IP Tunnel End Point Address in Session Object............... 7
   5.2.2. IP Tunnel Sender Address in Sender Template Object.......... 8
   5.2.3. Extended Tunnel ID.......................................... 8
   5.2.4. IF_ID RSVP_HOP Object for Numbered Interfaces............... 9
   5.2.5. Explicit Route Object (ERO)................................. 9
   5.2.6. Record Route Object (RRO)................................... 9
   5.3. IP Packet Source Address...................................... 9
   5.4. IP Packet Destination Address................................ 10
   6. Unnumbered Addressing.......................................... 10
   6.1. IGP.......................................................... 10
   6.1.1. Link Local/Remote Identifiers in OSPF-TE................... 11
   6.1.2. Link Local/Remote Identifiers in IS-IS/TE.................. 11
   6.2. Use of Addresses in RSVP-TE.................................. 11
   6.2.1. IF_ID RSVP_HOP Object for Unnumbered Interfaces............ 11
   6.2.2. Explicit Route Object (ERO)................................ 11
   6.3. Record Route Object (RRO).................................... 12
   6.4. LSP_Tunnel Interface ID Object............................... 12
   7. RSVP-TE Message Content........................................ 12
   7.1. ERO and RRO Addresses........................................ 12
   7.1.1. Strict Subobject in ERO.................................... 12
   7.1.2. Loose Subobject in ERO..................................... 13
   7.1.3. RRO........................................................ 13
   7.2. Component Link Identification................................ 14
   7.3. Forwarding Destination of Path Message with ERO.............. 15
   8. GMPLS Control Plane............................................ 15
   8.1. Control Channel Separation................................... 15
   8.2. Native and Tunneled Control Plane............................ 15
   8.3. Separation of Control and Data Plane Traffic................. 16
   9. Addresses in the MPLS and GMPLS TE MIB Modules................. 16
   9.1. Handling IPv6 Source and Destination Addresses............... 16

                         Expires October 2005                   [Page 2]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   9.1.1. Identifying LSRs........................................... 16
   9.1.2. Configuring GMPLS Tunnels.................................. 16
   9.2. Managing and Monitoring Tunnel Table Entries................. 17
   9.3. Mixed IPv4 and IPv6 Source and Destination................... 18
   10. Security Considerations....................................... 18
   11. IANA Considerations........................................... 18
   12. Full Copyright Statement ..................................... 19
   13. Intellectual Property......................................... 19
   14. Acknowledgement............................................... 19
   15. Authors' Addresses............................................ 20
   16. Contributors.................................................. 20
   17. References.................................................... 21
   17.1. Normative References........................................ 21
   17.2. Informative References ..................................... 23


   Changes from draft-ietf-ccamp-gmpls-addressing-00:

   - Updated sections 5.2.1 and 5.2.2 based on consensus in the WG

   - Moved common addressing text to new section 4

   - Added text in section 5.2.2 to address FA LSP

   - Integrated sections 4.2.3 and 5.2.1 as 7.2

   - Added new section 5.2.3 on Extended Tunnel ID

   - Integrated draft-davey-ccamp-gmpls-te-mib-ipv6-addr-00 in new
   section 9


1. Introduction

   This document explains and clarifies the use of addresses in networks
   that use GMPLS [RFC3945] as their control plane.  For the purposes of
   this document it is assumed that there is a one-to-one correspondence
   between control plane and data plane entities.  That is, each data
   plane switch has a unique control plane presence responsible for
   participating in the GMPLS protocols, and that each such control
   plane presence is responsible for a single data plane switch.  The
   combination of control plane and data plane entities is referred to
   as a Label Switching Router (LSR).  Various more complex deployment
   scenarios can be constructed, but these are out of the scope of this
   document.




                         Expires October 2005                   [Page 3]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   The document also covers the handling of IPv6 sources and
   destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB
   (Management Information Base) modules.


   Comments are solicited and should be addressed to the working group's
   mailing list at ccamp@ops.ietf.org and/or the author(s).


2. Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119, reference
   [RFC2119].


3. Terminology

   Note that the term 'Router ID' is used in two contexts within GMPLS.
   It may refer to an identifier for a participant in a routing
   protocol, or it may be an identifier for an LSR that participates in
   TE routing.  These could be considered as the control plane and data
   plane contexts.

   In this document, the contexts are distinguished by the following
   definitions.

   Loopback address - A loopback address is a stable IP address of the
   advertising router that is always reachable if there is any IP
   connectivity to it [RFC3630].  Thus, for example, an IPv4 127/24
   address is excluded from this definition.

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

   Router ID - The OSPF protocol version 2 [RFC2328] defines the Router
   ID to be a 32-bit network unique number assigned to each router
   running OSPF.  IS-IS [RFC1195] includes a similar concept in the
   System ID.  This document describes both concepts as the "Router ID"
   of the router running the routing protocol.  The Router ID is not
   required to be a reachable IP address, although an operator MAY set
   it to a reachable IP address on the same system.



                         Expires October 2005                   [Page 4]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   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]

   Data plane node - A vertex on the TE graph.  It is a data plane
   switch or router.  Data plane nodes are connected by TE links which
   are constructed from physical data links.  A data plane node is
   controlled through some combination of management and control plane
   actions.  A data plane node may be under full or partial control of a
   control plane node.

   Control plane node - A GMPLS protocol speaker.  It may be part of a
   data plane switch or may be a separate computer.  Control plane nodes
   are connected by control channels which are logical connectionless or
   connection-oriented paths in the control plane.  A control plane node
   is responsible for controlling zero, one or more data plane nodes.

   Interface ID - The Interface ID is defined in [RFC3477] and in
   section 9.1 of [RFC3471].

   TED - Traffic Engineering Database

   LSR - Label Switching Router

   FA - Forwarding Adjacency


4. Addressing in GMPLS Networks

   Both numbered and unnumbered links in the control plane MAY be
   supported.  The control channels are advertised by the routing
   protocol as normal links, which allows the routing of RSVP-TE and
   other control messages between the LSRs over the control plane
   network.

   It is RECOMMENDED that both numbered and unnumbered links in the data
   plane be supported.

   Addressing for numbered and unnumbered links is described in sections
   5 and 6 of this document respectively.


5. Numbered Addressing

   When numbered addressing is used, addresses are assigned to each node
   and link in both control and data planes in GMPLS networks.  A TE
   Router ID is defined to identify the LSR for TE purposes.  It is a


                         Expires October 2005                   [Page 5]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   requirement stated in [RFC3477] that the TE Router ID MUST be a
   reachable address in the control plane.

   The reason why the TE Router ID must be a reachable IP address is
   because in GMPLS, control and data plane names/addresses are not
   completely separated.  An Explicit Route Object (ERO) signaled as a
   part of a Label Switched Path (LSP) setup message contains an LSP
   path specified in data plane addresses, namely TE Router IDs and TE
   link IDs.  The message needs to be forwarded as an IP/RSVP packet
   between LSRs that manage data plane nodes along the path.  Hence,
   each LSR along the path needs to resolve the next hop data plane
   address into the next hop control plane address before the message
   could be forwarded to the next hop.  Generally speaking there is a
   need for a module/protocol that discovers and manages control plane/
   data plane address bindings for the address spaces to be completely
   separated.  In this case, the TE Router ID could be just a network
   unique number.  Mandating that TE Router ID be a reachable IP address
   in the control plane eliminates the need for the above mentioned
   module - the TE Router ID of the next hop in the data plane can be
   used as the destination for IP packets encapsulating the LSP setup
   (RSVP Path) message as described in section 5.4.  Note that each TE
   link ID can always be resolved to the TE Router ID of the originating
   LSR by examining the Router Address TLV in the OSPF TE LSA, or the
   Traffic Engineering router ID TLV in IS-IS (see section 5.1.1).

   Alternatively, the GMPLS network MUST supply the binding between
   control plane and data plane addresses.  LMP [GMPLS-LMP] MAY be used
   to provide such binding.

   A physical interface address or a physical interface identifier is
   assigned to each physical interface connected to the data plane.  An
   interface address or an interface identifier is logically assigned to
   each TE link end associated with the physical data channel in the
   GMPLS domain.  A TE link may be installed as a logical interface.

   A numbered link is identified by a network unique identifier (e.g.,
   an IP address).

5.1. Interior Gateway Protocols

   We address in this section numbered addressing using two Interior
   Gateway Protocols (IGPs) that have extensions defined for GMPLS:
   OSPF-TE and IS-IS/TE.  The routing enhancements for GMPLS are defined
   in [GMPLS-RTG], [RFC3784], [GMPLS-OSPF] and [GMPLS-ISIS].

5.1.1. Router Address



                         Expires October 2005                   [Page 6]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   The Router Address is advertised in OSPF-TE using the Router Address
   TLV structure of the TE LSA [RFC3630].

   In IS-IS/TE, this is referred to as the Traffic Engineering router
   ID, which is carried in the advertised Traffic Engineering router ID
   TLV [RFC3784].

   The IGP protocols use this as a means to advertise the TE Router ID.

5.1.2. Link ID sub-TLV

   The Link ID sub-TLV [RFC3630] advertises the Router ID of the remote
   end of the TE link.  For point-to-point links, this is the Router ID
   of the neighbor.  Multi-access links are left for further study.

   Note that there is no correspondence in IS-IS to the Link ID sub-TLV
   in OSPF-TE.  Instead, IS-IS uses the extended IS reachability TLV
   [RFC3784] to carry the System ID, which we have defined in section 3
   as the Router ID for the purposes of this document.

5.1.3. Local Interface IP Address

   The Local Interface IP Address is advertised in:
   - the Local Interface IP Address sub-TLV in OSPF-TE
   - the IPv4 Interface Address sub-TLV in IS-IS/TE

   This is the ID of the local end of the numbered TE link.  It MUST be
   a network unique number.  It does not need to be a routable address
   in the control plane.

5.1.4. Remote Interface IP Address

   The Remote Interface IP Address is advertised in:
   - the Remote Interface IP Address sub-TLV in OSPF-TE
   - the IPv4 Neighbor Address sub-TLV in IS-IS/TE

   This is the ID of the remote end of the numbered TE link.  It MUST be
   a network unique number.  It does not need to be a routable address
   in the control plane.

5.2. Use of Addresses in RSVP-TE

5.2.1. IP Tunnel End Point Address in Session Object

   The IP tunnel end point address of the Session Object [RFC3209] is
   either an IPv4 or IPv6 address.



                         Expires October 2005                   [Page 7]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   It is RECOMMENDED that the IP tunnel endpoint address in the Session
   Object be set to the TE Router ID of the egress since the TE Router
   ID is a unique routable ID per node.

   Alternatively, the tunnel end point address MAY be set to the
   destination data plane address (i.e. the Remote Interface IP Address)
   if the ingress knows that address.

5.2.2. IP Tunnel Sender Address in Sender Template Object

   The IP tunnel sender address of the Sender Template Object [RFC3209]
   is either an IPv4 or IPv6 address.

   When an LSP is being set up that will not be used to form an FA, it
   is RECOMMENDED that the IP tunnel sender address in the Sender
   Template Object specifies the TE Router ID of the ingress LSR since
   the TE Router ID is a unique, routable ID per node.

   Alternatively, the tunnel sender address MAY be set to the sender
   data plane address (i.e. Local Interface IP Address).

   Note that when an LSP is intended to be used to support an FA, the
   sender address SHOULD be set to the address that will be assigned to
   the local end of the TE link (this is a data plane address that will
   be advertised as the Local Interface IP Address) [MPLS-HIER].

5.2.3. Extended Tunnel ID

   As described in [RFC 3209], the Extended Tunnel ID in the Session
   Object is normally set to all zeros.  Ingress nodes that wish to
   narrow the scope of a SESSION to the ingress-egress pair may place
   their IPv4 address here as a globally unique identifier.

   This specification allows any IPv4 address of the ingress.  While
   this is functional from the perspective of restricting the scope of
   the SESSION it does not allow any other LSR in the network to deduce
   anything from the value of this field.

   This document modifies [RFC 3209] to specify that the Extended Tunnel
   ID in the session object MUST be set to all zeros, or to the TE
   Router ID of the ingress.

   When an LSP is signaled for use as an FA and the FA will be numbered,
   the Sender Address in the Sender Template is set to the address of
   the FA at the ingress.  This means that the identity of the ingress
   cannot be immediately determined from the Sender Template because the
   FA has not been advertised through routing.  The TE Router ID carried
   in the Extended Tunnel ID can be used to identify the ingress of the

                         Expires October 2005                   [Page 8]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   FA, to enable easy correlation of the LSP with the advertised FA, and
   to allow the reverse direction FA to be advertised at once.

5.2.4. IF_ID RSVP_HOP Object for Numbered Interfaces

   1. IPv4/IPv6 Next/Previous Hop Address: The IPv4/IPv6 Next/Previous
      Hop Address in the IF ID RSVP HOP Object [RFC3473] in the Path
      and Resv messages specifies the IP reachable address of the
      control plane interface used to send those messages, or the TE
      Router ID of the node that is sending those messages.

   2. IPv4/IPv6 address in Value Field of the Interface_ID TLV: In both
      the Path and Resv messages, the IPv4/IPv6 address in the value
      field of the Interface ID TLV in the IF ID RSVP HOP Object
      [RFC3471] specifies the associated data plane local interface
      address of the downstream data channel belonging to the node
      sending the Path message and receiving the Resv message.

   We describe in section 7.2 the case of a bundled link.

5.2.5. Explicit Route Object (ERO)

   The IPv4/IPv6 address in the ERO provides a data-plane identifier of
   an abstract node, TE node or TE link to be part of the signaled LSP.

   We describe in section 7 the choice of addresses in the ERO.

5.2.6. Record Route Object (RRO)

   The IPv4/IPv6 address in the RRO provides a data-plane identifier of
   either a TE node or TE link that is part of the established LSP.

   We describe in section 7 the choice of addresses in the RRO.

5.3. IP Packet Source Address

   The IP packet source address is either an IPv4 or IPv6 address.

   The IPv4 or IPv6 source address of the packet that carries the RSVP-
   TE message MUST be a reachable address of the node sending the RSVP-
   TE message.  It is RECOMMENDED that a stable IPv4 or IPv6 address of
   the node be used as a source address of the IP packet.

   In case the source address of the received IP packet containing the
   Path message is used as the destination address of the Resv message
   (see section 4.4), setting a stable IPv4 or IPv6 address in the Path
   message is beneficial for reliable control-plane transmission.  This
   allows for robustness when one of control-plane interfaces is down.

                         Expires October 2005                   [Page 9]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005



5.4. IP Packet Destination Address

   The IP packet destination address is either an IPv4 or IPv6 address.

   The IP destination address of the packet that carries the RSVP-TE
   message is a control-plane reachable address of the next hop or
   previous hop node along the LSP.

   A Path message is sent to the next hop node.  It is RECOMMENDED that
   a stable IPv4 or IPv6 address of the next hop node be used as the IP
   destination address of the packet that carries the RSVP-TE message.
   This address MAY be the TE Router ID of the next hop node or a
   reachable next-hop (stable) IPv4 or IPv6 address.

   A Resv message is sent to the previous hop node.  It is RECOMMENDED
   that the IPv4 or IPv6 destination of a Resv message be any of the
   following:
   - The IPv4 or IPv6 source address of the received IP packet
     containing the Path message,
   - A stable IPv4 or IPv6 address of the previous node (found by
     consulting the TED and referencing the upstream data plane
     interface),
   - The value in the received PHOP Object field.


6. Unnumbered Addressing

   In this section, we describe unnumbered addressing used in GMPLS to
   refer to different objects and their significance.  Unnumbered
   addressing is supported for a data plane.

   An unnumbered link is identified by the combination of TE Router ID
   and a node-unique Interface ID.

   Section 5.1.1 describes how a TE Router ID is advertised.  The TE
   Router ID is used in addition to the node-unique Interface ID to
   identify an unnumbered link in the data plane. In more complex
   implementation scenarios where an IGP router advertises TE link
   information for more than one LSR, the Router ID cannot be used to
   identify the unnumbered link as it does not uniquely identify the
   LSR, while on the other hand the TE Router ID uniquely identifies the
   LSR.

6.1. IGP

   We address in this section unnumbered addressing using OSPF-TE and
   IS-IS/TE.

                         Expires October 2005                  [Page 10]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


6.1.1. Link Local/Remote Identifiers in OSPF-TE

   Link Local and Link Remote Identifiers are carried in OSPF using a
   single sub-TLV of the Link TLV [GMPLS-OSPF]. They advertise the IDs
   of an unnumbered TE link's local and remote ends respectively.  Link
   Local/Remote Identifiers are numbers unique within the scopes of the
   advertising LSR and the LSR managing the remote end of the link
   respectively [RFC3477].  Note that these numbers are not network
   unique and therefore cannot be used as TE link end addresses on their
   own.  An unnumbered TE link end network-wide identifier is comprised
   of a TE Router ID associated with the link local end, followed by the
   link local identifier [RFC3477].

6.1.2. Link Local/Remote Identifiers in IS-IS/TE

   The Link Local and Link Remote Identifiers are carried in IS-IS using
   a single sub-TLV of the extended IS reachability TLV.  Link
   identifiers are exchanged in the Extended Local Circuit ID field of
   the "Point-to-Point Three-Way Adjacency" IS-IS Option type [GMPLS-
   ISIS].  The same discussion in 6.1.1 applies here.

6.2. Use of Addresses in RSVP-TE

   An unnumbered address used for data plane identification consists of
   the TE Router ID and the associated interface ID.

6.2.1. IF_ID RSVP_HOP Object for Unnumbered Interfaces

   The interface ID field in the IF_INDEX TLV specifies the interface of
   the data channel for that unnumbered interface.

   In both the Path message and the Resv message, the value of the
   interface ID in the IF_INDEX TLV specifies the associated local
   interface ID of the downstream data channel belonging to the node
   sending the Path message and receiving the Resv message.

   We describe in section 7.2 the case of a bundled link.

6.2.2. Explicit Route Object (ERO)

   For unnumbered interfaces in the ERO, the interface ID is either the
   incoming or outgoing interface of the TE link with respect to the
   GMPLS-capable LSR.

   We describe in section 7 the choice of addresses in the ERO.



                         Expires October 2005                  [Page 11]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


6.3. Record Route Object (RRO)

   For unnumbered interfaces in the RRO, the interface ID is either the
   incoming or outgoing interface of the TE link with respect to the
   GMPLS-capable LSR.

   We describe in section 7 the choice of addresses in the RRO.

6.4. LSP_Tunnel Interface ID Object

   The LSP_TUNNEL_INTERFACE_ID Object includes the LSR's Router ID and
   Interface ID as described in [RFC3477] to specify an unnumbered
   Forward Adjacency Interface ID.  The Router ID of the GMPLS-capable
   LSR MUST be set to the TE Router ID.


7. RSVP-TE Message Content

7.1. ERO and RRO Addresses

7.1.1. Strict Subobject in ERO

   Implementations making limited assumptions about the content of an
   ERO when processing a received Path message may cause
   interoperability issues.

   A subobject in the Explicit Route Object (ERO) includes an address
   specifying an abstract node (i.e., a group of nodes), a simple
   abstract node (i.e., a specific node), or a specific interface of a
   TE link in the data plane, depending on the level of control required
   [RFC3209].

   In case one subobject is strict, any of the following options are
   valid:
   1. Address or AS number specifying a group of nodes
   2. TE Router ID
   3. Incoming TE link ID
   4. Outgoing TE link ID optionally followed by one or two Label
      subobjects
   5. Incoming TE link ID and Outgoing TE link ID optionally followed by
      one or two Label subobjects
   6. TE Router ID and Outgoing TE link ID optionally followed by one or
      two Label subobjects
   7. Incoming TE link ID, TE Router ID and Outgoing TE link ID
      optionally followed by one or two Label subobjects

   The label value that identifies a single unidirectional resource
   between two nodes may be different from the perspective of upstream

                         Expires October 2005                  [Page 12]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   and downstream nodes.  This is typical in the case of fiber
   switching, because the label value is a number indicating the
   port/fiber.  This is also possible in case of lambda switching,
   because the label value is a number indicating the lambda, but may
   not be the value directly indicating the wavelength value (e.g., 1550
   nm).

   The value of a label in RSVP-TE object MUST indicate the value from
   the perspective of the sender of the object/TLV [RFC3471].  This rule
   MUST be applied to all types of object/TLV.

   Therefore, the label field in the Label ERO subobject MUST include
   the value of the label for the upstream node's identification of the
   resource.

7.1.2. Loose Subobject in ERO

   There are two differences between Loose and Strict subobject.

   A subobject marked as a loose hop in an ERO MUST NOT be followed by a
   subobject indicating a label value [RFC3473].

   A subobject marked as a loose hop in an ERO SHOULD never include an
   identifier (i.e., address or ID) of outgoing interface.

   There is no way to specify in the ERO whether a subobject is
   associated with the incoming or outgoing TE link.  This is
   unfortunate because the address specified in a loose subobject is
   used as a target for the path computation, and there is a big
   difference for the path selection process whether the intention is to
   reach the target node over the specified link (the case of incoming
   TE link) or to reach the node over some other link, so that it would
   be possible to continue the path to its final destination over the
   specified link (the case of outgoing TE link).

   In the case where a subobject in an ERO is marked as a loose hop and
   identifies an interface, the subobject SHOULD include the address of
   the Incoming interface specifying the TE link in the data plane.

7.1.3. RRO

   When a node adds one or more subobjects to an RRO and sends the Path
   or the Resv message including the RRO for the purpose of recording
   the node's addresses used for an LSP, the subobjects (i.e. number,
   each type, and each content) added by the node SHOULD be the same in
   the Path RRO and Resv RRO.  The intention is that they report the
   path of the LSP, and that the operator can use the results
   consistently.  At any transit node, it SHOULD be possible to

                         Expires October 2005                  [Page 13]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005



   construct the path of the LSP by joining together the RRO from the
   Path and the Resv messages.

   It is also important that a whole RRO on a received Resv message can
   be used as input to an ERO on a Path message.

   Therefore, in case that a node adds one or more subobjects to an RRO,
   any of the following options are valid:
   1. TE Router ID
   2. Incoming TE link ID
   3. Outgoing TE link ID optionally followed by one or two Label
      subobjects
   4. Incoming TE link ID and Outgoing TE link ID optionally followed by
      one or two Label subobjects
   5. TE Router ID and Outgoing TE link ID optionally followed by one or
      two Label subobjects
   6. Incoming TE link ID, TE Router ID and Outgoing TE link ID
      optionally followed by one or two Label subobjects

   Option (4) is RECOMMENDED considering the importance of the record
   route information to the operator.


7.2. Component Link Identification

   When using a bundled link for a data channel, a component link
   identifier is specified in the Interface Identification TLV in the
   IF_ID RSVP_HOP Object in order to fully specify the resource.  The
   Interface Identification TLV is IF_INDEX TLV (Type 3) in the case of
   an unnumbered component link and IPv4 TLV (Type 1) or IPv6 TLV (Type
   2) in the case of a numbered component link.

   A component link for the upstream data channel may differ from that
   for the downstream data channel in the case of a bi-directional
   LSP.  In this case, the Interface Identification TLV specifying a
   downstream interface is followed by another Interface Identification
   TLV specifying an upstream interface.

   Note that identifiers in TLVs for upstream and downstream data
   channels in both sent Path and received Resv messages are specified
   from the viewpoint of a node sending the Path message and receiving
   the Resv message, using the identifiers belonging to the node.

   The interface identifier in ERO and RRO SHOULD specify the identifier
   of the bundled link, but not the component link, in case of a bundled
   link.  This is because information about the bundled link is flooded,
   but information about the component links is not.  Alternatively, a
   component link identifier MAY be recorded in the RRO because it might

                         Expires October 2005                  [Page 14]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005



   provide useful information for a fault diagnosis tool, and it also
   MAY be included in the ERO in order to specify one component link for
   a specific reason.

7.3. Forwarding Destination of Path Message with ERO

   The final destination of the Path message is the Egress node that is
   specified by the tunnel end point address in the Session object.
   The Egress node MUST NOT forward the corresponding Path message
   downstream, even if the ERO includes the outgoing interface ID of the
   Egress node for the Egress control [RFC4003].


8. GMPLS Control Plane

8.1. Control Channel Separation

   In GMPLS, a control channel can be separated from the data channel
   and there is not necessarily a one-to-one association of a control
   channel to a data channel.  Two adjacent nodes in the data plane may
   have multiple IP hops between them in the control plane.

   There are two broad types of separated control planes: native and
   tunneled.  These differ primarily in the nature of encapsulation used
   for signaling messages, which also results in slightly different
   address handling with respect to the control plane address.

8.2. Native and Tunneled Control Plane

   It is RECOMMENDED that all implementations support a native control
   plane.

   If the control plane interface is unnumbered, the RECOMMENDED value
   for the control plane address is the TE Router-ID.

   For the case where two adjacent nodes have multiple IP hops between
   them in the control plane, then as stated in section 9 of [RFC3945],
   implementations SHOULD use the mechanisms of section 8.1.1 of [MPLS-
   HIER] whether they use LSP Hierarchy or not.  Note that section 8.1.1
   of [MPLS-HIER] applies to an "FA-LSP" as stated in that section but
   also to a "TE link" for the case where a normal TE link is used.
   Note also that a hop MUST NOT decrement the TTL of the received RSVP-
   TE message.

   For a tunneled control plane, the inner RSVP-TE and IP messages
   traverse exactly one IP hop.  The IP TTL of the outermost IP header
   SHOULD be the same as for any network message sent on that network.
   Implementations receiving RSVP-TE messages on the tunnel interface

                         Expires October 2005                  [Page 15]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   MUST NOT compare the RSVP-TE TTL to either of the IP TTLs received.
   Implementations MAY set the RSVP-TE TTL to be the same as the IP TTL
   in the innermost IP header.

8.3. Separation of Control and Data Plane Traffic

   Data traffic MUST NOT be transmitted through the control plane.  This
   is crucial when attempting PSC (Packet-Switching Capable) GMPLS with
   separated control and data channels.


9. Addresses in the MPLS and GMPLS TE MIB Modules

   This section defines a method of defining or monitoring an LSP tunnel
   using the MPLS TE MIB module [RFC3812] and GMPLS TE MIB module
   [GMPLS-TEMIB] where the ingress and/or egress routers are identified
   using 128-bit IPv6 addresses.  That is, where the
   mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the
   mplsTunnelTable [RFC3812] cannot be used to carry the tunnel end
   point address and Extended Tunnel Id fields from the signaled Session
   Object because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is
   in use.

9.1. Handling IPv6 Source and Destination Addresses

9.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 router ID.  The 32-bit router ID
   may be, for example, the OSPFv3 router ID [RFC2740] or the ISIS IPv4
   TE Router ID [RFC3784].

9.1.2. Configuring GMPLS Tunnels

   When setting up RSVP TE tunnels, it is common practice to copy the
   values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields
   in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel
   ID and IPv4 tunnel end point address fields, respectively, in the
   RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209].

   This approach cannot be used when the ingress and egress routers are
   identified by 128-bit IPv6 addresses as the mplsTunnelIngressLSRId
   and mplsTunnelEgressLSRId fields are defined to be 32-bit values
   [RFC3811] and [RFC3812].

   Instead, the IPv6 addresses SHOULD be configured in the mplsHopTable
   as the first and last hops of the mplsTunnelHopTable entries defining

                         Expires October 2005                  [Page 16]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   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 router IDs for ingress and egress LSR respectively.

   The mplsTunnelHopTableIndex MUST be set to a non-zero value.  That
   is, an explicit route MUST be specified.

   The first hop of the explicit route MUST have mplsTunnelHopAddrType
   field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field
   set to a global scope IPv6 address of the ingress router that is
   reachable in the control plane.

   The last hop of the explicit route MUST have mplsTunnelHopAddrType
   field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field
   set to a global scope IPv6 address of the egress router that is
   reachable in the control plane.

   The ingress router SHOULD set the signaled values of the Extended
   Tunnel ID and IPv6 tunnel end point address fields, respectively, of
   the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [RFC3209] from the
   mplsTunnelHopIpAddr object of the first and last hops in the
   configured explicit route.

9.2. Managing and Monitoring Tunnel Table Entries

   The TE MIB module may be used for managing and monitoring MPLS and
   GMPLS TE LSPs, as well as configuring them as described in section
   8.2.  This function is particularly important at egress and transit
   LSRs.

   For a tunnel with IPv6 source and destination addresses, an LSR
   implementation SHOULD return values in the mplsTunnelTable as follows
   (where "normal" behavior is the default taken from [RFC3812]).

   The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.



                         Expires October 2005                  [Page 17]

                 draft-ietf-ccamp-gmpls-addressing-01        June 2005


   The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to
   32-bit router IDs.  That is, each transit and egress router maps from
   the IPv6 address in the Extended Tunnel ID field to the 32-bit router
   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
   router ID of the egress LSR.

9.3. Mixed IPv4 and IPv6 Source and Destination

   This section has focused on the case where both ingress and egress
   are identified by IPv6 addresses.  It is also possible that only one
   of the two addresses comes from the IPv6 space.  In this case only
   the text applying to the ingress or egress (as appropriate) should be
   applied.


10. 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.


11. IANA Considerations

   This document defines no new code points and requires no action from
   IANA.

















                         Expires October 2005                  [Page 18]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


12. Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


13. 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.


14. Acknowledgement

   The authors would like to thank Adrian Farrel for the helpful
   discussions and the feedback he gave on the document.  In addition,
   Jonathan Sadler, Hidetsugu Sugiyama, Deborah Brungard and Dimitri
   Papadimitriou provided helpful comments.

                         Expires October 2005                  [Page 19]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005




15. Authors' Addresses

   Kohei Shiomoto
   NTT Network Service Systems Laboratories
   3-9-11 Midori
   Musashino, Tokyo 180-8585
   Japan
   Email: shiomoto.kohei@lab.ntt.co.jp

   Rajiv Papneja
   Isocore Corporation
   12359 Sunrise Valley Drive, Suite 100
   Reston, Virginia 20191
   United States of America
   Phone: +1-703-860-9273
   Email: rpapneja@isocore.com

   Richard Rabbat
   Fujitsu Laboratories of America
   1240 East Arques Ave, MS 345
   Sunnyvale, CA 94085
   United States of America
   Phone: +1-408-530-4537
   Email: richard@us.fujitsu.com


16. Contributors

   Alan Davey
   Data Connection Ltd
   Phone: +44 20 8366 1177
   Email: Alan.Davey@dataconnection.com

   Yumiko Kawashima
   NTT Network Service Systems Lab
   Email: kawashima.yumiko@lab.ntt.co.jp

   Thomas D. Nadeau
   Cisco Systems, Inc.
   300 Apollo Drive
   Chelmsford, MA 01824
   Phone: +1-978-244-3051
   Email: tnadeau@cisco.com

   Ashok Narayanan
   Cisco Systems, Inc.

                         Expires October 2005                  [Page 20]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   Email: ashokn@cisco.com

   Eiji Oki
   NTT Network Service Systems Laboratories
   Midori 3-9-11
   Musashino, Tokyo 180-8585, Japan
   Email: oki.eiji@lab.ntt.co.jp

   Lyndon Ong
   Ciena Corporation
   Email: lyong@ciena.com

   Vijay Pandian
   Sycamore Networks
   Email: Vijay.Pandian@sycamorenet.com

   Hari Rakotoranto
   Cisco Systems
   Email: hrakotor@cisco.com


17. References

17.1. Normative References

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels," BCP 14, IETF RFC 2119, March
                 1997.

   [RFC2328]     Moy, J., "OSPF Version 2," RFC 2328, April 1998.

   [RFC3209]     Awduche, D., et al, "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., Rekhter, Y., "Signalling Unnumbered
                 Links in Resource ReSerVation Protocol - Traffic
                 Engineering (RSVP-TE)," RFC 3477, January 2003.



                         Expires October 2005                  [Page 21]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


   [RFC3630]     Katz, D., Kompella, K. et al., "Traffic Engineering
                 (TE) Extensions to OSPF Version 2," RFC 3630,
                 September 2003.

   [RFC3667]     Bradner, S., "IETF Rights in Contributions", BCP 78,
                 IETF RFC 3667, February 2004.

   [RFC3668]     Bradner, S., "Intellectual Property Rights in IETF
                 Technology", BCP 79, IETF RFC 3668, February 2004.

   [RFC3811]     Nadeau, T. and J. Cucchiara, (Eds.), "Definitions of
                 Textual Conventions (TCs) for Multiprotocol Label
                 Switching (MPLS) Management", IETF RFC 3812, June
                 2004.

   [RFC3812]     Srinivasan, C., Viswanathan, A. and Nadeau, T.,
                 "Multiprotocol Label Switching (MPLS) Traffic
                 Engineering (TE) Management Information Base (MIB)",
                 IETF 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.

   [GMPLS-OSPF]  Kompella, K. and Y. Rekhter (Eds.), "OSPF Extensions
                 in Support of Generalized Multi-protocol Label
                 Switching," work in progress, draft-ietf-ccamp-ospf-
                 gmpls-extensions-12.txt, October 2003.

   [GMPLS-RTG]   Kompella, K. and Y. Rekhter (Eds.), "Routing
                 Extensions in Support of Generalized Multi-protocol
                 Label Switching," work in progress, draft-ietf-ccamp-
                 gmpls-routing-09.txt, October 2003.

   [GMPLS-TEMIB] Nadeau, T. and A. Farrel (Eds.), "Generalized
                 Multiprotocol Label Switching (GMPLS) Traffic
                 Engineering Management Information Base," work in
                 progress, draft-ietf-ccamp-gmpls-te-mib-09.txt, June
                 2005.

   [MPLS-HIER]   Kompella, K. and Y. Rekhter, "LSP Hierarchy with
                 Generalized MPLS TE," work in progress, draft-ietf-
                 mpls-lsp-hierarchy-08.txt, March 2002.



                         Expires October 2005                  [Page 22]

                 draft-ietf-ccamp-gmpls-addressing-01          June 2005


17.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, April 1998.

   [RFC3784]     Smit, H. and T. Li, "Intermediate System to
                 Intermediate System (IS-IS) Extensions for Traffic
                 Engineering (TE)," RFC 3784, June 2004.

   [GMPLS-ISIS]  Kompella, K. and Y. Rekhter (Eds.), "IS-IS Extensions
                 in Support of Generalized Multi-Protocol Label
                 Switching," work in progress, draft-ietf-isis-gmpls-
                 extensions-19.txt, October 2003.

   [GMPLS-LMP]   Lang, J. (Ed.), "Link Management Protocol (LMP)," work
                 in progress, draft-ietf-ccamp-lmp-10.txt, October
                 2003.





























                         Expires October 2005                  [Page 23]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/