Network Working Group George Swallow Internet Draft Cisco Systems, Inc Expiration Date:
JulyAugust 2003 John Drake Calient Networks, Inc Hirokazu Ishimatsu Japan Telecom Yakov Rekhter Juniper Networks, Inc JanuaryFebruary 2003 GMPLS RSVP Support for the Overlay Model draft-ietf-ccamp-gmpls-overlay-00.txtdraft-ietf-ccamp-gmpls-overlay-01.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 statusThe list of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in ancurrent Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directory, see http://www.ietf.org/shadow.html.Directories can be accessed at http://www.ietf.org/shadow.html Copyright (C) The Internet Society (2003). All Rights Reserved. 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. 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 11 Full Copywrite Statement ............................... 9 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 'CN'. The four boxes around the edge marked "Overlay Network" represent four islands of a single network overlaid network. Only the nodes of this network with TE links into the core network are 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. HoweverHowever, one possible means is 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][RFC3473] 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 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],[RFC3471], [BUNDLE], and [RSVP-TE-UNUM].[RFC3477]. 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]. 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. 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].[RFC3473]. 7. Security Considerations This draft imposes no new security risks over [GMPLS-RSVP].[RFC3473]. 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. 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,[RFC3471] Berger, L., "Generalized MPLS -Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling-08.txt, April 2002. [GMPLS-RSVP] Ashwood-Smith, P. et. al,RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized MPLS - RSVP-TESignaling Functional Description", draft-ietf-mpls-generalized-rsvp-te-07.txt, April 2002.RSVP-TE Extensions", RFC 3473, January 2003. [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.draft-ietf-ccamp-gmpls-architecture-04.txt, Feb., 2003. [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. [RSVP-UNNUM][RFC3477] Kompella, K., and Rekhter, Y., "Signalling Unnumbered Links in RSVP-TE", Internet Draft, draft-ietf-mpls-rsvp-unnum-07.txt, July, 2002.RFC 3477, January 2003. [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: firstname.lastname@example.org Hirokazu Ishimatsu Japan Telecom Co., Ltd. 2-9-1 Hatchobori, Chuo-ku, Tokyo, 104-0032, Japan Tel: +81 3 5540 8493 Email: email@example.com Yakov Rekhter Juniper Networks, Inc. Email: firstname.lastname@example.org George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Phone: +1 978 497 8143 Email: email@example.com 11. Full Copywrite Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.