Network Working Group                                       K. Shiomoto 
Internet Draft                                                      NTT 
Updates: RFC 3473                                            R. Papneja 
Proposed Category: Standards Track                              Isocore 
Expires: April 2007                                           R. Rabbat 
                                                                Fujitsu 
                                                       October 22, 2006 
                                    
 
                                      
      Use of Addresses in Generalized Multi-Protocol Label Switching 
                             (GMPLS) Networks 
                 draft-ietf-ccamp-gmpls-addressing-05.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 

   This Internet-Draft will expire on April 22, 2007. 

 

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 

 
 
 
Shiomoto                Expires April 22, 2007                 [Page 1] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   gained in deployments and interoperability testing and proper 
   interpretation of published RFCs. 

   The document specifies a proper approach for the interpretation and 
   choice of address and identifier fields within GMPLS protocols and 
   references specific control plane usage models.  It also examines 
   some common GMPLS Resource Reservation Protocol-Traffic Engineering 
   (RSVP-TE) signaling message processing issues and recommends 
   solutions.  Finally, it discusses how to handle IPv6 sources and 
   destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB 
   (Management Information Base) modules.  

Conventions used in this document 

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

Table of Contents 

    
   1. Introduction...................................................3 
   2. Changes from draft-ietf-ccamp-gmpls-addressing-04..............4 
   3. Terminology....................................................4 
   4. Support of Numbered and Unnumbered Links.......................6 
   5. Numbered Addressing............................................6 
      5.1. Addresses in IGPs.........................................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. Addresses in RSVP-TE......................................7 
         5.2.1. IP Tunnel End Point Address in Session Object........7 
         5.2.2. IP Tunnel Sender Address in Sender Template Object...8 
         5.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces........8 
         5.2.4. Explicit Route Object (ERO)..........................9 
         5.2.5. Record Route Object (RRO)............................9 
         5.2.6. IP Packet Source Address.............................9 
         5.2.7. IP Packet Destination Address........................9 
   6. Unnumbered Addressing.........................................10 
      6.1. Addresses in IGPs........................................11 
         6.1.1. Link Local/Remote Identifiers in OSPF-TE............11 
         6.1.2. Link Local/Remote Identifiers in IS-IS/TE...........11 
      6.2. Addresses in RSVP-TE.....................................12 
         6.2.1. IF_ID RSVP_HOP Object for Unnumbered Interfaces.....12 
         6.2.2. Explicit Route Object (ERO).........................12 
         6.2.3. Record Route Object (RRO)...........................12 
 
 
Shiomoto                Expires April 22, 2007                 [Page 2] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

         6.2.4. LSP_Tunnel Interface ID Object......................12 
   7. RSVP-TE Message Content.......................................12 
      7.1. ERO and RRO Addresses....................................13 
         7.1.1. Strict Subobject in ERO.............................13 
         7.1.2. Loose Subobject in ERO..............................14 
         7.1.3. RRO.................................................14 
         7.1.4. Label Record subobject in RRO.......................15 
      7.2. Component Link Identification............................16 
      7.3. Forwarding Destination of Path Message with ERO..........16 
   8. Topics Related to the GMPLS Control Plane.....................17 
      8.1. Control Channel Separation...............................17 
      8.2. Native and Tunneled Control Plane........................17 
      8.3. Separation of Control and Data Plane Traffic.............17 
   9. Addresses in the MPLS and GMPLS TE MIB Modules................17 
      9.1. Handling IPv6 Source and Destination Addresses...........18 
         9.1.1. Identifying LSRs....................................18 
         9.1.2. Configuring GMPLS Tunnels...........................18 
      9.2. Managing and Monitoring Tunnel Table Entries.............19 
   10. Security Considerations......................................19 
   11. IANA Considerations..........................................20 
   12. Acknowledgments..............................................20 
   13. Contributors.................................................21 
   14. References...................................................22 
      14.1. Normative References....................................22 
      14.2. Informative References..................................23 
   Authors' Addresses...............................................24 
   Intellectual Property Statement..................................24 
   Disclaimer of Validity...........................................25 
   Copyright Statement..............................................25 
   Acknowledgment...................................................25 
    
1. Introduction 

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


 
 
Shiomoto                Expires April 22, 2007                 [Page 3] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

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

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

2. Changes from draft-ietf-ccamp-gmpls-addressing-04 

   o  Fixed section numbering references in RFC 4206 

   o  Removed paragraph about setting IP tunnel sender address for 
      dynamically set up numbered FAs (end of 5.2.2) 

   o  Removed recommendation about the kind of RRO to prefer 

   o  Updated section 4 

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. 

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







 
 
Shiomoto                Expires April 22, 2007                 [Page 4] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

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

   o  TE link: "A TE link is a representation in the IS-IS/OSPF Link 
      State advertisements and in the link state database of certain 
      physical resources, and their properties, between two GMPLS 
      nodes." [RFC3945] 

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

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

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

   o  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 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 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. 
 
 
Shiomoto                Expires April 22, 2007                 [Page 5] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

4. Support of Numbered and Unnumbered Links 

   The links in the control and data planes MAY be numbered or 
   unnumbered.  Implementations have made decisions to support either 
   numbered or unnumbered addressing.  The argument for numbered 
   addressing is to simplify troubleshooting while the argument for 
   unnumbered addressing is to save on IP address resources.  The end 
   result is that this leads to lack of interoperability.  Given the 
   importance of having interoperable GMPLS implementations, a control 
   plane implementation SHOULD support both numbered and unnumbered 
   links. 

   A node that receives advertised link information that includes both 
   numbered and unnumbered addresses SHOULD be able to accept this 
   advertisement. 

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

5. Numbered Addressing 

   When numbered addressing is used, addresses are assigned to each node 
   and link in both control and data planes in GMPLS networks. 

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

5.1. 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 [RFC3784], [RFC4202], [RFC4203] and [RFC4205]. 

5.1.1. Router Address 

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

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

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



 
 
Shiomoto                Expires April 22, 2007                 [Page 6] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

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: 

   o  the Local Interface IP Address sub-TLV in OSPF-TE 

   o  the IPv4 Interface Address sub-TLV in IS-IS/TE 

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

5.1.4. Remote Interface IP Address 

   The Remote Interface IP Address is advertised in: 

   o  the Remote Interface IP Address sub-TLV in OSPF-TE 

   o  the IPv4 Neighbor Address sub-TLV in IS-IS/TE 

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

5.2. Addresses in RSVP-TE 

   The different subsections describe the use of addresses in the 
   signaling protocol. 

5.2.1. IP Tunnel End Point Address in Session Object 

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



 
 
Shiomoto                Expires April 22, 2007                 [Page 7] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   On transmission, the IP tunnel endpoint address in the Session Object 
   SHOULD 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. 

   On reception of the control packet, the IP tunnel endpoint address 
   could be any address of the remote system, as long as the receiver 
   knows how to route to it. 

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

5.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces 

   There are two addresses used in this object: 

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

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

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




 
 
Shiomoto                Expires April 22, 2007                 [Page 8] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

5.2.4. Explicit Route Object (ERO) 

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

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

5.2.5. Record Route Object (RRO) 

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

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

5.2.6. IP Packet Source Address 

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

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

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

5.2.7. IP Packet Destination Address 

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

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

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

   A Resv message is sent to the previous hop node.  It is RECOMMENDED 
   that the IPv4 or IPv6 destination of a Resv message be any of the 
   following: 
 
 
Shiomoto                Expires April 22, 2007                 [Page 9] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   o  The IPv4 or IPv6 source address of the received IP packet 
      containing the Path message, 

   o  A stable IPv4 or IPv6 address of the previous node (found by 
      consulting the TED and referencing the upstream data plane 
      interface), 

   o  The value in the received PHOP Object field. 

6. Unnumbered Addressing 

   In this section, we describe unnumbered addressing as used in GMPLS 
   to refer to different objects and their significance.  A TE Router ID 
   is defined to identify the LSR for TE purposes.  An unnumbered link 
   is identified by the combination of TE Router ID and a node-unique 
   Interface ID.  It is a requirement stated in [RFC3477] that the TE 
   Router ID MUST be a reachable address in the control plane. 

   For unnumbered links, an Explicit Route Object (ERO) signaled as a 
   part of a Label Switched Path (LSP) setup message contains the 
   desired route of an LSP and may include the identifiers for nodes and 
   links specified using TE Router IDs and TE link IDs.  

   Since the LSP setup message must be forwarded within the control 
   plane, each LSR along the path needs to resolve the next hop in the 
   ERO into a control plane address of the LSR (signaling controller) 
   responsible for handling the next hop. 

   Mandating that TE Router ID be a reachable IP address in the control 
   plane simplifies the mapping from ERO hop identifiers to LSR control 
   plane addresses for use as described in section 5.2.7.  

   If a node is identified in the ERO, the TE Router ID used in the ERO 
   can be immediately used to address the control plane message. 

   o  If an unnumbered TE link is identified in the ERO, the identifier 
      includes the TE Router ID and can be immediately used to address 
      the control plane message. That is, the TE Router ID is used as 
      the destination for IP packets encapsulating the LSP setup (RSVP 
      Path) message as described in section 5.2.7. 

   o  If a numbered TE link is identified in the ERO, the correct 
      control plane address (the TE Router ID) can be found in the IGP 
      advertisement of the identified TE link - the Router Address TLV 
      in the OSPF TE LSA, or the Traffic Engineering router ID TLV in 
      IS-IS (see section 5.1.1). 

 
 
Shiomoto                Expires April 22, 2007                [Page 10] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   An alternative to using the TE Router ID to identify nodes or 
   unnumbered links in the ERO is to use some other IP-format identifier 
   unique to the data plane address space.  In this case some other 
   mechanism is required to allow an LSR to map between data plane 
   identifiers and control plane addresses.  Such a mechanism could be 
   provided through configuration or through LMP [RFC4204]. 

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

   Section 5.1.1 describes how a TE Router ID is advertised.  The TE 
   Router ID is used in addition to the node-unique Interface ID to 
   identify an unnumbered link in the data plane.  In more complex 
   implementation scenarios (not covered in this draft) 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. Addresses in IGPs 

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

6.1.1. Link Local/Remote Identifiers in OSPF-TE 

   Link Local and Link Remote Identifiers are carried in OSPF using a 
   single sub-TLV of the Link TLV [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 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 [RFC4205].  
   The same discussion in 6.1.1 applies here. 
 
 
Shiomoto                Expires April 22, 2007                [Page 11] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

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

6.2.1. IF_ID RSVP_HOP Object for Unnumbered Interfaces 

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

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

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

6.2.2. Explicit Route Object (ERO) 

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

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

6.2.3. Record Route Object (RRO) 

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

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

6.2.4. LSP_Tunnel Interface ID Object 

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

7. RSVP-TE Message Content 

   We discuss in this section the addresses used in the RSVP-TE 
   messages, including ERO and RRO addresses as well as component link 
   identification. 


 
 
Shiomoto                Expires April 22, 2007                [Page 12] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

7.1. ERO and RRO Addresses 

   We address strict and loose subobjects in ERO separately, then 
   discuss the RRO. 

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.  It is RECOMMENDED that implementations 
   support the receipt of ERO options applicable to their hardware 
   capabilities.  Note that implementations do not need to support the 
   options containing Component Link IDs if they do not support link 
   bundling [RFC4201]. 

   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 is 
   valid: 

   1. Address or AS number specifying a group of nodes 

   2. TE Router ID 

   3. Incoming TE link ID 

   4. Outgoing TE link ID optionally followed by Component Interface ID 
      subobject and/or one or two Label subobjects 

   5. Incoming TE link ID and Outgoing TE link ID optionally followed by 
      Component Interface ID subobject and/or one or two Label 
      subobjects 

   6. TE Router ID and Outgoing TE link ID optionally followed by 
      Component Interface ID subobject and/or one or two Label 
      subobjects 

   7. Incoming TE link ID, TE Router ID and Outgoing TE link ID 
      optionally followed by Component Interface ID subobject and/or one 
      or two Label subobjects 

   The label value that identifies a single unidirectional resource 
   between two nodes may be different from the perspective of upstream 
 
 
Shiomoto                Expires April 22, 2007                [Page 13] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   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.  ERO processing at region boundaries is done according to 
   section 6.2 of [RFC4206]. 

7.1.2. Loose Subobject in ERO 

   There are two differences between Loose and Strict subobjects. 

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

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

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

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

7.1.3. RRO 

   When a node adds one or more subobjects to an RRO and sends the Path 
   or the Resv message including the RRO for the purpose of recording 
   the node's addresses used for an LSP, the subobjects (i.e. number, 
   each type, and each content) added by the node SHOULD be the same in 
   the Path RRO and Resv RRO.  The intention is that they report the 
 
 
Shiomoto                Expires April 22, 2007                [Page 14] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   path of the LSP, and that the operator can use the results 
   consistently.  At any transit node, it SHOULD be possible to 
   construct the path of the LSP by joining together the RRO from the 
   Path and the Resv messages. 

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

   Therefore, in case a node adds one or more subobjects to an RRO, any 
   of the following options are valid: 

   1. TE Router ID 

   2. Incoming TE link ID 

   3. Outgoing TE link ID optionally followed by Component Interface ID 
      subobject and/or one or two Label subobjects 

   4. Incoming TE link ID and Outgoing TE link ID optionally followed by 
      Component Interface ID subobject and/or one or two Label 
      subobjects 

   5. TE Router ID and Outgoing TE link ID optionally followed by 
      Component Interface ID subobject and/or one or two Label 
      subobjects 

   6. Incoming TE link ID, TE Router ID and Outgoing TE link ID 
      optionally followed by Component Interface ID subobject and/or one 
      or two Label subobjects 

   An implementation MAY choose any of these options and MUST be 
   prepared to receive an RRO that contains any of these options. 

7.1.4. Label Record subobject in RRO 

   Routes and labels can be recorded via the RECORD_ROUTE object (RRO) 
   present in both RSVP Path and Resv messages. When a sender node needs 
   route and label recording, the Label Recording flag is set in the 
   SESSION_ATTRIBUTE object and an RRO is included in the Path message 
   as described in [RFC3209]. 

   As described in [RFC3209] the RRO in a Path message is built up hop 
   by hop and Label Record subobjects SHOULD be included when requested 
   and when the label information is available. Also as described in 
   [RFC3209], for a Resv message "the processing mirrors that of the 
   Path" and "The only difference is that the RRO in a Resv message 
   records the path information in the reverse direction."  This means 
 
 
Shiomoto                Expires April 22, 2007                [Page 15] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   that when Label Record objects are added to the RRO in a Path message 
   they SHOULD also be added to the RRO in the corresponding Resv 
   message. 

7.2. Component Link Identification 

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

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

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

   When a bundled link is used, an LSR constructing an ERO SHOULD 
   include the identifier of the bundled link and MAY choose to not 
   include an identifier of the component link.  This is because 
   information about the bundled link is flooded but information about 
   the component links is not.  Alternatively, the ERO MAY also include 
   an identifier of a component link if this identifier is known to the 
   LSR that constructs the ERO, and if the LSR wishes to constrain the 
   LSP to a particular component link. 

   Component links MAY be identified within RROs in addition to the 
   bundled link.  This might provide useful information for fault 
   diagnosis, and can supply information for the construction of EROs, 
   for example for pinning. 

7.3. Forwarding Destination of Path Message with ERO 

   The final destination of the Path message is the Egress node that is 
   specified by the tunnel end point address in the Session object. 

   The Egress node MUST NOT forward the corresponding Path message 
   downstream, even if the ERO includes the outgoing interface ID of the 
   Egress node for Egress control [RFC4003]. 

 
 
Shiomoto                Expires April 22, 2007                [Page 16] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

8. Topics Related to the GMPLS Control Plane 

8.1. Control Channel Separation 

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

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

8.2. Native and Tunneled Control Plane 

   It is suggested that all implementations support a native control 
   plane to enable better interoperability. 

   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 6.1.1 of 
   [RFC4206] whether they use LSP Hierarchy or not.  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.   

   Note also that a hop MUST NOT decrement the TTL of the received RSVP-
   TE message. 

   For a tunneled control plane, the inner RSVP-TE and IP messages 
   traverse exactly one IP hop.  The IP TTL of the outermost IP header 
   SHOULD be the same as for any network message sent on that network.  
   Implementations receiving RSVP-TE messages on the tunnel interface 
   MUST NOT compare the RSVP-TE TTL to either of the IP TTLs received.  
   Implementations MAY set the RSVP-TE TTL to be the same as the IP TTL 
   in the innermost IP header. 

8.3. Separation of Control and Data Plane Traffic 

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

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 
 
 
Shiomoto                Expires April 22, 2007                [Page 17] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   [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 LSR ID.  The 32-bit LSR ID is the 
   OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784].  
   Note that these are different from TE router ID (See Section 3). 

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 
   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 LSR respectively. 
 
 
Shiomoto                Expires April 22, 2007                [Page 18] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   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. 

   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. 

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 
 
 
Shiomoto                Expires April 22, 2007                [Page 19] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   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. 

12. Acknowledgments 

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































 
 
Shiomoto                Expires April 22, 2007                [Page 20] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

13. Contributors 

   Alan Davey 
   Data Connection Ltd 
    
   Phone: +44 20 8366 1177        
   Email: Alan.Davey@dataconnection.com 
    
    
   Yumiko Kawashima 
   NTT Network Service Systems Lab 
   Japan 
    
   Email: kawashima.yumiko@lab.ntt.co.jp 
    
    
   Kaori Shimizu 
   NTT Network Service Systems Lab 
    
   Email: shimizu.kaori@lab.ntt.co.jp 
    
    
   Thomas D. Nadeau 
   Cisco Systems, Inc. 
   300 Apollo Drive 
   Chelmsford, MA 01824 
   United States of America 
    
   Phone: +1-978-244-3051 
   Email: tnadeau@cisco.com 
    
    
   Ashok Narayanan 
   Cisco Systems, Inc. 
    
   Email: ashokn@cisco.com 
    
    
   Eiji Oki 
   NTT Network Service Systems Laboratories 
   Midori 3-9-11 
   Musashino, Tokyo 180-8585 
   Japan 
    
   Email: oki.eiji@lab.ntt.co.jp 
    
    
 
 
Shiomoto                Expires April 22, 2007                [Page 21] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   Lyndon Ong 
   Ciena Corporation 
   PO Box 308  
   Cupertino, CA 95015 
   United States of America 
    
   Phone: +1 408 705 2978 
   Email: lyong@ciena.com 
    
    
   Vijay Pandian 
   Sycamore Networks 
    
   Email: Vijay.Pandian@sycamorenet.com 
    
    
   Hari Rakotoranto 
   Cisco Systems 
    
   Email: hrakotor@cisco.com 
    

14. References 

14.1. Normative References 

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

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

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 
             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 
             Tunnels", RFC 3209, December 2001. 

   [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 
             (GMPLS) Signaling Functional Description", RFC 3471, 
             January 2003.  

   [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic 
             Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 

   [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 
             in Resource ReSerVation Protocol - Traffic Engineering 
             (RSVP-TE)", RFC 3477, January 2003. 

 
 
Shiomoto                Expires April 22, 2007                [Page 22] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

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

   [RFC3811] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 
             (TE) Extensions to OSPF Version 2", RFC 3630, September 
             2003. 

   [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 
             "Multiprotocol Label Switching (MPLS) Traffic Engineering 
             (TE) Management Information Base (MIB)", RFC 3812,      
             June 2004.  

   [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 
             (GMPLS) Architecture", RFC 3945, October 2004. 

   [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", 
             RFC 4003, February 2005. 

   [RFC4201] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in 
             MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 

   [RFC4202] Kompella, K. and Y. Rekhter (Eds.), "Routing Extensions in 
             Support of Generalized Multi-protocol Label Switching",   
             RFC 4202, October 2005. 

   [RFC4203] Kompella, K. and Y. Rekhter (Eds.), "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. 

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

   [RFC4204] Lang, J. (Ed.), "Link Management Protocol (LMP)", RFC 4204, 
             October 2005. 
 
 
Shiomoto                Expires April 22, 2007                [Page 23] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   [RFC4205] Kompella, K. and Y. Rekhter (Eds.), "Intermediate System to 
             Intermediate System (IS-IS) Extensions in Support of 
             Generalized Multi-Protocol Label Switching (GMPLS)", RFC 
             4205, October 2005. 

   [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-15.txt, April 2006. 

Authors' Addresses 

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

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

   Richard Rabbat 
   Fujitsu Laboratories of America 
   1240 East Arques Ave, MS 345 
   Sunnyvale, CA 94085 
   United States of America 
       
   Phone: +1 408-530-4537 
   Email: rabbat@alum.mit.edu 
    

Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
 
 
Shiomoto                Expires April 22, 2007                [Page 24] 

Internet-Draft    Use of Addresses in GMPLS Networks       October 2006 
    

   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   ietf-ipr@ietf.org. 

Disclaimer of Validity 

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

Copyright Statement 

   Copyright (C) The Internet Society (2006). 

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

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 






 
 
Shiomoto                Expires April 22, 2007                [Page 25]