Internet DRAFT - draft-ccamp-gmpls-overlay

draft-ccamp-gmpls-overlay











Network Working Group                                     George Swallow
Internet Draft                                        Cisco Systems, Inc
Expiration Date: July 2003
                                                              John Drake
                                                   Calient Networks, Inc

                                                      Hirokazu Ishimatsu
                                                           Japan Telecom

                                                           Yakov Rekhter
                                                   Juniper Networks, Inc

                                                            January 2003


                GMPLS RSVP Support for the Overlay Model


                    draft-ccamp-gmpls-overlay-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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."

   To view the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
   Directory, see http://www.ietf.org/shadow.html.

Abstract

   Generalized MPLS defines both routing and signaling protocols for the
   creation of Label Switched Paths (LSPs) in various transport
   technologies.  These protocols can be used to support a number of
   deployment scenarios.  This memo addresses the application of GMPLS
   to the overlay model.







Swallow, et al.                                                 [Page 1]

Internet Draft      draft-ccamp-gmpls-overlay-00.txt        January 2003




Contents

    1      Introduction  ...........................................   3
    2      Addressing  .............................................   4
    3      ERO Processing  .........................................   5
    3.1    Path Message without ERO  ...............................   6
    3.2    Path Message with ERO  ..................................   6
    3.3    Explicit Label Control  .................................   6
    4      RRO Processing  .........................................   6
    5      Notification  ...........................................   7
    6      Connection Deletion  ....................................   7
    7      Security Considerations  ................................   7
    8      Acknowledgments  ........................................   8
    9      References  .............................................   8
    9.1    Normative References  ...................................   8
    9.2    Informative References  .................................   8
   10      Authors' Addresses  .....................................   9
































Swallow, et al.                                                 [Page 2]

Internet Draft      draft-ccamp-gmpls-overlay-00.txt        January 2003


1. Introduction

   Generalized MPLS defines both routing and signaling protocols for the
   creation of Label Switched Paths (LSPs) in various transport
   technologies.  These protocols can be used to support a number of
   deployment scenarios.  In a peer model, edge-nodes support both a
   routing and a signaling protocol.  The protocol interactions between
   an edge-node and a core node are the same as between two core-nodes.
   In the overlay model, the core-nodes act more as a closed system.
   The edge nodes do not participate in the routing protocol instance
   that runs among the core nodes; in particular, the edge nodes are
   unaware of the topology of the core nodes.  There may, however, be a
   routing protocol interaction between a core node and an edge node for
   the exchange of reachability information to other edge nodes.


   Overlay                                                    Overlay
   Network        +----------------------------------+        Network
 +----------+     |                                  |     +----------+
 |   +----+ |     |  +-----+    +-----+    +-----+   |     | +----+   |
 |   |    | |     |  |     |    |     |    |     |   |     | |    |   |
 | --+ EN +-+-----+--+ CN  +----+ CN  +----+  CN +---+-----+-+ EN +-- |
 |   |    | |  +--+--|     |    |     |    |     |   |     | |    |   |
 |   +----+ |  |  |  +--+--+    +--+--+    +--+--+   |     | +----+   |
 |          |  |  |     |          |          |      |     |          |
 +----------+  |  |     |          |          |      |     +----------+
               |  |     |          |          |      |
 +----------+  |  |     |          |          |      |     +----------+
 |          |  |  |  +--+--+       |       +--+--+   |     |          |
 |   +----+ |  |  |  |     |       +-------+     |   |     | +----+   |
 |   |    +-+--+  |  | CN  +---------------+ CN  |   |     | |    |   |
 | --+ EN +-+-----+--+     |               |     +---+-----+-+ EN +-- |
 |   |    | |     |  +-----+               +-----+   |     | |    |   |
 |   +----+ |     |                                  |     | +----+   |
 |          |     +----------------------------------+     |          |
 +----------+                  Core Network                +----------+
   Overlay                                                    Overlay
   Network                                                    Network

                                             Legend:   EN  -  Edge Node
                                                       CN  -  Core Node

                   Figure 1:  Overlay Reference Model

   Figure 1 shows a reference network.  The core network is represented
   by the large box in the center.  It contains five core-nodes marked
   represent four islands of a single network overlaid network.  Only
   the nodes of this network with TE links into the core network are



Swallow, et al.                                                 [Page 3]

Internet Draft      draft-ccamp-gmpls-overlay-00.txt        January 2003


   shown.  These nodes are called edge-nodes; the terminology is in
   respect to the core network, not the overlay network.  Note that each
   box marked "Overlay Network" could contain many other nodes.  Such
   nodes are not shown; they do not participate in the signalling
   described in this document.  Only he edge-nodes can signal to set up
   links across the core to other edge-nodes.  Once a link is
   established, presumably the edge-node will inform the other nodes of
   the overlay network of its existence.  How this is accomplished is
   beyond the scope of this document.  However using a forwarding
   adjacency as described in [MPLS-HIER].

   In the overlay model there may be restrictions on what may be
   signaled between an edge-node and a core-node.  This memo addresses
   the application of GMPLS to the overlay model.  Specifically it
   addresses RSVP procedures between an edge-node and a core-node in the
   overlay model.  All RSVP procedures are assumed to be identical to
   [GMPLS-RSVP] except as noted in this document.

   This document primarily addresses interactions between an edge-node
   and it's adjacent (at the data plane) core-node.  Except where noted,
   the term core-node refers to the node which is immediately adjacent
   to an edge-node across a particular data plane interface.  The term
   core-nodes, however, refers to all nodes in the core.

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



2. Addressing

   Addresses for edge-nodes in the overlay model are drawn from the same
   address space as the edge-nodes use to address their adjacent core-
   nodes.  This may be the same address space as used by the core-nodes
   to communicate among themselves or it may be a VPN space supported by
   the core-nodes as an overlay.

   To be more specific, an edge-node and its attached core-node must
   share the same address space which is used by GMPLS.  A set of
   <edge-node, core-node> tuples share the same address space if the
   edge-nodes in the set could establish LSPs (through the core-nodes)
   among themselves (note that edge-nodes in the set may be a subset of
   all the edge-nodes). The address space used by the core-nodes to
   communicate among themselves may, but need not be shared with the
   address space used by any of the <edge-node, core-node> tuples.

   An edge-node is identified by either a single IP address representing



Swallow, et al.                                                 [Page 4]

Internet Draft      draft-ccamp-gmpls-overlay-00.txt        January 2003


   its Node-ID, or by one or more numbered TE links that connect the
   edge-node to the core-nodes.  Core-nodes are assumed to be ignorant
   of any other addresses associated with an edge-node (i.e. addresses
   which are not used in signaling connections through the GMPLS core).

   An edge-node need only know its own address, an address of the
   adjacent core-node, and know (or be able to resolve) the address of
   any other edge-node to which it wishes to connect.

   A core-node need only know (and track) the addresses on interfaces
   between that core-node and its attached edge-nodes, as well as the
   Node IDs of those edge-nodes.  In addition, a core-node needs to know
   the interface addresses and Node IDs of other edge-nodes to which an
   attached edge-node is permitted to connect.

   When forming a SENDER_TEMPLATE the ingress edge-node includes either
   its Node-ID or the address of one of its numbered TE links.  In the
   latter case the connection will only be made over this interface.

   When forming a SESSION_OBJECT, the ingress edge-node includes either
   the Node-ID of the egress edge-device or the address of one of the
   egress' numbered TE links.  In the latter case the connection will
   only be made over this interface.  The Extended_Tunnel_ID of the
   SESSION Object is set to either zero or to an address of the ingress
   edge-device.

   Links may be either numbered or unnumbered.  Further, links may be
   bundled or unbundled.  See [GMPLS-ARCH], [GMPLS-SIG], [BUNDLE], and
   [RSVP-TE-UNUM].



3. ERO Processing

   An edge-node MAY include an ERO.  A core-node MAY reject a Path
   message that contains an ERO.  Such behavior is controlled by
   (hopefully consistent) configuration.  If a core-node rejects a Path
   message due to the presence of an ERO it SHOULD return an PathErr
   message with an error code of "Unknown object class" toward the
   sender. This causes the path setup to fail.

   Further a core-node MAY accept EROs which only include the ingress
   edge-node, the ingress core-node, the egress core-node and the egress
   edge-node.  This is to support explicit label control on the edge-
   node interface, see below.  If a core-node rejects a Path message due
   to the presence of an ERO not of the permitted format it SHOULD
   return an PathErr message with an error code of Bad Explicit Route
   Object as defined in [RFC3209].



Swallow, et al.                                                 [Page 5]

Internet Draft      draft-ccamp-gmpls-overlay-00.txt        January 2003


3.1. Path Message without ERO

   When a core-node receives a Path message from an edge-node that
   contains no ERO, it MUST calculate a route to the destination and
   include that route in a ERO, before forwarding the PATH message.  One
   exception would be if the egress edge-node were also adjacent to this
   core-node.  If no route can be found, the core-node SHOULD return a
   PathErr message with an error code and value of 24,5 - "No route
   available toward destination".


3.2. Path Message with ERO

   When a core-node receives a Path message from an edge-node that
   contains an ERO, it SHOULD verify the route against its topology
   database before forwarding the PATH message.  If the route is not
   viable, then a PathErr message with an error code and value of 24,5 -
   "No route available toward destination" should be returned.


3.3. Explicit Label Control

   In order to support explicit label control and full identification of
   the egress link an ingress edge-node may include an ERO that consists
   of only the last hop.  This is signaled by setting the first
   subobject of the ERO to the node-ID of the egress core-node with the
   L-bit set.  Following this subobject are all other subobjects
   necessary to identify the link and labels as they would normally
   appear.



4. RRO Processing

   An edge-node MAY include an RRO.  A core-node MAY remove the RRO from
   the Path message before forwarding it.  Further the core-node may
   remove the RRO from a Resv message before forwarding it to the edge-
   node.  Such behavior is controlled by (hopefully consistent)
   configuration.

   Further a core-node MAY edit the RRO in a Resv message such that it
   includes only the subobjects from the egress core-node through the
   egress edge-node.  This is to allow the ingress node to be aware of
   the selected link and labels on at the far end of the connection.







Swallow, et al.                                                 [Page 6]

Internet Draft      draft-ccamp-gmpls-overlay-00.txt        January 2003


5. Notification

   An edge-node MAY include a NOTIFY_REQUEST object in both the Path and
   Resv messages it generates.  A core-node MAY remove the
   NOTIFY_REQUEST object from the Path or Resv message before forwarding
   it.  Core-nodes may send Notification messages to edge-nodes which
   have included the NOTIFY_REQUEST object.

   Further if no NOTIFY_REQUEST object is present in the Path or Resv
   message (either because it was not included or because it was
   removed) then the core-node adjacent to the edge-node may include a
   NOTIFY_REQUEST object to set its value to its own address.



6. Connection Deletion

   RSVP currently deletes connections using either a single pass
   PathTear message, or a ResvTear and PathTear message combination.
   Upon receipt of the PathTear message, a node deletes the connection
   state and forwards the message. In optical networks, however, it is
   possible that the deletion of a connection (e.g., removal of the
   cross-connect) in a node may cause the connection to be perceived as
   failed in downstream nodes (e.g., loss of frame, loss of light,
   etc.). This may in turn lead to management alarms and perhaps the
   triggering of restoration/protection for the connection.

   To address this issue, the graceful connection deletion procedure
   SHOULD be followed. Under this procedure, an ADMIN_STATUS object MUST
   be sent in Path or Resv message along the connection's path to inform
   all nodes enroute of the intended deletion, prior to the actual
   deletion of the connection. The procedure is described in [GMPLS-
   RSVP].



7. Security Considerations

   This draft imposes no new security risks over [GMPLS-RSVP].  In fact
   it represents a lower trust model between the core and edge-nodes as
   the core is permitted to hide its topology from the edge-nodes.  The
   core is also permitted to restrict the actions of edge-nodes by
   filtering out specific RSVP objects.








Swallow, et al.                                                 [Page 7]

Internet Draft      draft-ccamp-gmpls-overlay-00.txt        January 2003


8. Acknowledgments

   The authors would like to thank Kireeti Kompella, Jonathan Lang,
   Dimitri Papadimitriou, Dimitrios Pendarakis and Bala Rajagopalan for
   their comments and input.



9. References

9.1. Normative References

[GMPLS-SIG]  Ashwood-Smith, P. et al, "Generalized MPLS -
             Signaling Functional Description", Internet Draft,
             draft-ietf-mpls-generalized-signaling-08.txt,
             April 2002.

[GMPLS-RSVP] Ashwood-Smith, P. et. al, "Generalized MPLS - RSVP-TE
             Signaling Functional Description",
             draft-ietf-mpls-generalized-rsvp-te-07.txt,
             April 2002.

[RFC2205]    Braden, R. Ed. et al, "Resource ReserVation Protocol
             -- Version 1 Functional Specification", RFC 2205,
             September 1997.

[RFC2961]    Berger, L. et al, "RSVP Refresh Overhead Reduction
             Extensions", RFC 2961, April 2001

[RFC3209]    Awduche, et al, "RSVP-TE: Extensions to RSVP for
             LSP Tunnels", RFC 3209, December 2001.



9.2. Informative References

[GMPLS-ARCH] Mannie, E, et al., "Generalized Multi-Protocol
             Label Switching (GMPLS) Architecture", Internet Draft,
             draft-ietf-ccamp-gmpls-architecture-03.txt, Aug., 2002.


[MPLS-HIER]  Kompella, K., and Rekhter, Y., "LSP Hierarchy with
             MPLS TE", Internet Draft,
             draft-ietf-mpls-lsp-hierarchy-08.txt, Sep., 2001.

[BUNDLE]     Kompella, K., Rekhter, Y., and Berger, L., "Link
             Bundling in MPLS Traffic Engineering", Internet Draft,
             draft-ietf-mpls-bundle-04.txt,  July, 2002.



Swallow, et al.                                                 [Page 8]

Internet Draft      draft-ccamp-gmpls-overlay-00.txt        January 2003


[RSVP-UNNUM] Kompella, K., and Rekhter, Y., "Signalling Unnumbered
             Links in RSVP-TE", Internet Draft,
             draft-ietf-mpls-rsvp-unnum-07.txt, July, 2002.

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





10. Authors' Addresses

   <need info for other authors>
   John Drake
   Calient Networks
   5853 Rue Ferrari
   San Jose, CA 95138
   Phone:  +1 408 972 3720
   Email:  jdrake@calient.net

   Hirokazu Ishimatsu
   Japan Telecom Co., Ltd.
   2-9-1 Hatchobori, Chuo-ku, Tokyo, 104-0032, Japan
   Tel: +81 3 5540 8493
   Email: hirokazu.ishimatsu@japan-telecom.co.jp

   Yakov Rekhter
   Juniper Networks, Inc.
   Email:  yakov@juniper.net

   George Swallow
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA 01824
   Phone:  +1 978 497 8143
   Email:  swallow@cisco.com














Swallow, et al.                                                 [Page 9]

Internet Draft      draft-ccamp-gmpls-overlay-00.txt        January 2003





















































Swallow, et al.                                                [Page 10]