CCAMP Working Group D. Ceccarelli, Ed. Internet-Draft Ericsson Intended status: Informational I. Bryskin Expires: April 25, 2013 ADVA Optical Networking V. Beeram J. Drake Juniper Networks C. Margaria Nokia Siemens Networks October 22, 2012 Multi-domain network integration framework in the context of overlay model draft-many-ccamp-gmpls-overlay-model-01 Abstract This document provides a framework for the integration of GMPLS based multi domain networks in the context of the overlay model. It defines terminology, requirements, interfaces and use cases characterizing the overlay model. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 25, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Ceccarelli, et al. Expires April 25, 2013 [Page 1] Internet-Draft Overlay model framework October 2012 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overlay interfaces . . . . . . . . . . . . . . . . . . . . . . 6 3.1. GMPLS UNI . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. GMPLS E-NNI . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Pre-Provisioned Server Paths . . . . . . . . . . . . . 8 3.2.2. Virtual Links . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Virtual Nodes . . . . . . . . . . . . . . . . . . . . 11 4. Signaling: Info passed from Edge Network to Core network . . . 13 5. routing: Info passed from Core Network to Edge network . . . . 14 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Ceccarelli, et al. Expires April 25, 2013 [Page 2] Internet-Draft Overlay model framework October 2012 1. Introduction Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies and scenarios. In multi domain scenarios, the GMPLS enables two different architectures: the peer model and the overlay model[RFC4208]. In the peer model edge nodes support both a routing and a signaling protocol and their interaction with the core nodes is basically the same that occurs among core nodes. On the other side, in the overlay case, the interaction between edge nodes and core nodes is limited to signaling messages exchange and a very limited, if any, routing information exchange between core nodes and edge nodes regarding other edge nodes reachability. The edge nodes do not participate in the routing instance running in the core network domain and do not have any information about its topology. This memo is focused on the overlay model frameworks and in particular addresses: definitions, methods (i.e. UNI interface, E-NNI interface) and use cases. 1.1. Terminology 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. Definitions Ceccarelli, et al. Expires April 25, 2013 [Page 3] Internet-Draft Overlay model framework October 2012 Client Client Domain +---------+ +-------------------+ Domain +-------+ | | | | +--------+ | |Access | | | | | | | +---+ | Link | +---+ | | +---+ +---+ | | +---+ | | |CN1|------------+SN1++========+SN3+----+SN4+==========+SN3+ | | +---+ | +-----+--+---+ | | +---+ +---+ | | +---+ | | | | | | | | | | | | | | | | | | | | | | | | | +-------+ | | | | | | | | +--------+ | | | | | +---+ | | +-------+ | | | | | |SN5| | | +--------+ | | | | | | | +---+ | | | | | | | | | | | | | | | | | +---+-+-+ | +---+ | | +-------+---+ | | +---+ | | |CN2+---------|--+SN2+===================+SN6+=========+SN5| | | +---+ |Access | +---+ |Int.Dom.Link +---+ | | +---+ | | | Link | | | | | | | | +---------+ +-------------------+ | | +-------+ Service Provider Service Provider +--------+ Client Domain Domain Client Domain Domain === - inter-domain TE-links ### - end to end LSP Figure 1: Overlay reference model + Client Domain: it is also called overlay network [RFC4208]. It is composed by the network elements directly connected to the server domain and has no knowledge of the server network topology but can retrieve routing information on how to reach other areas of the client domain via the server domain. The interanction with the server domain occurs via the overlay interfaces. + Client node: Node of the client domain directly connected to an access link. Client nodes can be ingress/egress nodes for overlay services and ingress/egress/transit nodes for overlay end-to-end LSPs. + Service Provider Domain: Network acting as server layer for the edge network. Multiple server domains can be interconnected. + Service provider node: Node of the server network without interfaces on access TE-Links. + Border Service Provider node: Node of the server network connected to access TE-links. It can receive signaling messages Ceccarelli, et al. Expires April 25, 2013 [Page 4] Internet-Draft Overlay model framework October 2012 from client nodes and provide them with routing information regarding the other client networks connected to the server network. + Access TE-link: TE-links between client nodes and server nodes. It only can be an interface supporting a transport technolgy (e.g. MPLS-TP, OTN, WDM). + Inter Domain TE-link: TE-links between server border nodes belonging to different server domains. A server network can be composed by multiple server domains. If an overlay interface is supposed to forward server domain topology information to the client network it must include topology information of all the server domain. As a consequence topology information of each server domain must be forwarded on the inter domain TE-links. Client Client Domain +---------+ +-------------------+ Domain +-------+ | | | | +--------+ | |Access | | | | | | +--+ | +---+ | Link | +---+ | | +---+ +######################## | | |CN1|------------+SN1++========+SN3+----+SN4************CN3****** | | +---+ | +-----+--+---+ | | +---+ +#*-+ | | +---+ | +--+ | | | | | | | | #* | | | | | | | | | | | #* | | | +-------+ | | | | | | #* | +--------+ | | | | | +---+ #* | +-------+ | | | | | |SN5| #* | +--------+ | | | | | | | +---+ #* | | | +--+ | | | | | | | | #* | | | | |#############################################---+ | | +---+ | | | | |CN2+************+SN2+********************SN6+=========+CN4| | ++++ | +---+ |Access | +---+ |Int.Dom.Link +---+ | | +---+ | | | Link | | | | | | | | +---------+ +-------------------+ | | +-------+ Service Provider Service Provider +--------+ Client Domain Domain Client Domain Domain *** - overlay service ### - end to end LSP Figure 2: Overlay services and interfaces Ceccarelli, et al. Expires April 25, 2013 [Page 5] Internet-Draft Overlay model framework October 2012 + Overlay interface: Overlay interfaces are used for setting up overlay services and allow the exchange of signaling and routing information. Two types of overlay interfaces are defined in the following, namely the GMPLS UNI and GMPLS E-NNI. Both of them allows inter-connecting devices in the client domain which are directly connected to the server domain and in either cases the service provides domain real topology is not known to the client domain but only a virtualized version. ++ GMPLS UNI: defined in [RFC4208] and augmented by [INC- ROUTE], [TE-REC], [XRO-SUB] and [OBJ-FUNC]. ++ GMPLS E-NNI: defined in [E-NNI]. The E-NNI interface allows signaling and routing information exchange via the access TE- link. + Overlay service: It can only be established from a client node to a client node and have the service provider nodes as transit LSRs. Overlay services are injected by the client nodes into the domains where its interfaces (other than the overlay ones) belong to so to allow the establishment of end to end LSP crossing the client and service provider domains. 3. Overlay interfaces 3.1. GMPLS UNI [statements]: - the GMPLS UNI consider the service provider domains as opaque, no inter-domain routing IGP is used and paths (TE link) are not exported. Some (limited) properties of TE links may be requested by the client and may be provided by the server layer (based on policy), e.g., SRLG, metrics, etc. - As there is no service provider domain IGP visibility the path computaiton constraints are to be considered by the border service provider path computation element. Those parameters can be provided to the border service provider PCE using PCEP or using signaling. - The lack of IGP visibility do also require the routing information described in section 5 to be provided by signaling protocol (RRO) - once a path is computed (and set up), it can be exported to the client layer as a TE-link with given TE parameters and SRLG Ceccarelli, et al. Expires April 25, 2013 [Page 6] Internet-Draft Overlay model framework October 2012 recording [requirements]: U1. Must support signaling from client domain to server domain U2. Must support a path computaiton request in the server domain with given constraints U3. No server domain topology is exported to the client domain a priori (i.e. before the setup of a path in the server layer) U4. May support routing information towards the client server a posteriori (i.e. once a path is computed and set up, it may be exported to the client layer as a TE-link with given TE parameters and SRLG recording U5. The path computation in the server domain can be either distributed (i.e. performed by the service provider border node) or centralized by a PCE. U6. ... 3.2. GMPLS E-NNI [statements]: [x] In comparaison to GMPLS UNI the GMPLS E-NNI offer virtual topology visibility of the service provider network to the client. This offer the advantage of reusing of IGP mechanisms and information but may require more coordination from the border service provider nodes to offer such topology. [x] paths in the service provider domain are precomputed. They can be pre-signaled (i.e. fully committed FA-LSPs) or just pre- computed and sharable (virtual TE-links) - FA-LSPs and virtual TE-links are exported to the client domain via the E-NNI interface with given properties (i.e. TE parameters). Virtual TE-links are activated via an external trigger (e.g. NMS) [] TE-links may then injected in the domain the client node belongs to and used for end to end LSPs [requirements]: Ceccarelli, et al. Expires April 25, 2013 [Page 7] Internet-Draft Overlay model framework October 2012 E1. Must support signaling from client domain to server domain E2. Must support routing information towards the client server a priori (i.e. a set of pre-computed or pre-provisioned paths in the server domain must be exported to the client domain as provisioned or virtual TE-links with given TE parameters and SRLG recording E3. No server domain topology is exported to the client domain E4. Server layer domain may be exported to the client domain as a virtual node E5. The path computation in the server domain can be either distributed (i.e. performed by the service provider border node) or centralized by a PCE. E6. ... [description] In order to be able to compute an end-to-end path between a pair of client nodes, the client TE topology must be sufficiently augmented to indicate via some fashion the paths through the server topology which can provide connectivity between nodes in the client topology. In other words, the feasible paths across each server network domain should be made available in terms of TE links/nodes to all the clients. GMPLS-ENNI provides the tools required to do this augmentation. There are different ways of augmenting the client topology. This document discusses 3 approaches in the following subsections. 3.2.1. Pre-Provisioned Server Paths In this approach, the paths in the server domain are provisioned up front and advertised as TE links in the client network domain. This means that relevant server network resources are committed before the service is setup in the client network. Ceccarelli, et al. Expires April 25, 2013 [Page 8] Internet-Draft Overlay model framework October 2012 Physical Topology C1..C4 - Client Nodes ----------------- S1..S6 - Server Nodes S1,S3,S4,S6 - Border Nodes *********** - Preprovisioned Path +---+ +---+ +---+ +---+ +---+ | C1|------| S1|--------| S2|---------| S3|---------| C2| +---+ +---+ +---+ +---+ +---+ */ \* */ \ */ \* */ \ */ \* */ \ */ \* */ \ */ \*/ \ +---+ +---+ +---+ +---+ +---+ | C3|---------| S4|---------| S5|---------| S6|---------| C4| +---+ +---+ +---+ +---+ +---+ Client TE Topology +++++ - Client TE Link ------------------ ===== | N | - Client TE Node ===== ===== ===== ===== ===== | C1|++++++| S1| | S3|+++++++++| C2| ===== ===== ===== ===== +++ +++ +++ +++ ++++ ===== ===== ===== ===== | C3|+++++++++| S4| | S6|+++++++++| C4| ===== ===== ===== ===== Figure 3: Pre-provisioned paths In Figure 3 the Server Domain Path [S4-S2-S5-S3] is pre-provisioned and the TE-Link [S4-S3] is advertised in to the Client-Domain. This makes the computation of an end-to-end Client Domain Path from C3 to C2 possible. Ceccarelli, et al. Expires April 25, 2013 [Page 9] Internet-Draft Overlay model framework October 2012 3.2.2. Virtual Links In this approach, potential paths in the server domain are advertised as Virtual TE links in the client network domain. The Virtual TE link is advertised just like a real TE link and does not require the allocation of resources in the server domain. Physical Topology C1..C4 - Client Nodes ----------------- S1..S6 - Server Nodes S1,S3,S4,S6 - Border Nodes *-*-*-*-*-* - Potential Path +---+ +---+ +---+ +---+ +---+ | C1|------| S1|--------| S2|---------| S3|---------| C2| +---+ +---+ +---+ +---+ +---+ */ \- -/ \ -/ \* */ \ */ \- -/ \ -/ \* */ \ */ \-/ \ +---+ +---+ +---+ +---+ +---+ | C3|---------| S4|---------| S5|---------| S6|---------| C4| +---+ +---+ +---+ +---+ +---+ Client TE Topology +++++ - Client TE Link ------------------ ===== Virtual TE Link | N | - Client TE Node ===== ===== ===== ===== ===== | C1|++++++| S1| | S3|+++++++++| C2| ===== ===== ===== ===== +++ +++ +++ +++ ++++ ===== ===== ===== ===== | C3|+++++++++| S4| | S6|+++++++++| C4| ===== ===== ===== ===== Figure 4: Virtual TE Links Ceccarelli, et al. Expires April 25, 2013 [Page 10] Internet-Draft Overlay model framework October 2012 In Figure 4 , the Virtual TE-Link [S4-S3] is advertised into the client domain based on the presense of the potential path [S4-S2-S5-S3] in the server domain. This makes the computation of an end-to-end Client Domain Path from C3 to C2 possible. The resources in the server domain get provisioned only when the corresponding client service gets signaled. 3.2.3. Virtual Nodes In this approach, the server domain topology is presented to the clients as a Virtual TE Node. Ceccarelli, et al. Expires April 25, 2013 [Page 11] Internet-Draft Overlay model framework October 2012 Physical Topology C1..C4 - Client Nodes ----------------- S1..S6 - Server Nodes S1,S3,S4,S6 - Border Nodes +---+ +---+ +---+ +---+ +---+ | C1|------| S1|--------| S2|---------| S3|---------| C2| +---+ +---+ +---+ +---+ +---+ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ +---+ +---+ +---+ +---+ +---+ | C3|---------| S4|---------| S5|---------| S6|---------| C4| +---+ +---+ +---+ +---+ +---+ Client TE Topology +++++ - Client TE Link ------------------ ===== [VN] Virtual TE Node | N | - Client TE Node ===== ===== ===== | C1| | C2| ===== ===== +++ +++ +++ +++ +++ +++ ===== | VN| ===== +++ +++ +++ +++ +++ +++ ===== ===== | C3| | C4| ===== ===== Figure 5: Virtual node In Figure 5 , the Server Domain Topology is represented as a single Ceccarelli, et al. Expires April 25, 2013 [Page 12] Internet-Draft Overlay model framework October 2012 Virtual Node in the Client network. 4. Signaling: Info passed from Edge Network to Core network The client node may need to constraint the path used in the service provider domains.Those constraints may be : - Objective Functions - TE Metric for a loose segment - Node/Link/SRLG inclusion - Node/Link/SRLG exclusion - Path used by another LSP(from: draft-ali-xro-lsp-subobject) (from:draft-ali-objective-functions) - the ingress node may need to request remote node to perform path computation or expansion. In such cases, ingress node needs to convey the required objective function to the remote node, to enable it to perform the desired path computation. Similarly, there are cases the ingress needs to indicate a TE metric bound for a loose segment that is expanded by a remote node. (from: draft-ali-xro-lsp-subobject) - Moreover there are cases in which a remote node is requested to compute a path exluding LSPs currently existing or expected to exist withing the network. Hence what needs to be available to the remote node (ingress core node) is: + Objective function(draft-ali-objective-functions):A set of one or more specific optimization criteria that must be followed in expanding route of a TE-LSP in MPLS and GMPLS networks: Minimum TE Metric Cost, Minimum IGP Metric Cost, Minimum Latency, Minimum Latency Variation + Metric(draft-ali-objective-functions):the bound on the path metric that must not be exceeded for the loose segment to be considered as acceptable by the ingress node + Include Route(draft-ali-include-route):There are scenarios that require two or more LSPs or segments of LSPs to follow same route in the network: Explicit Inclusion Route Ceccarelli, et al. Expires April 25, 2013 [Page 13] Internet-Draft Overlay model framework October 2012 + Exclude Route(draft-ali-xro-lsp0subobject): + Exclude Route(RFC4874) 5. routing: Info passed from Core Network to Edge network (draft-beeram) - It is important to note that topology information is layer-specific; e.g. path computation and qualification operations occur within a given layer, and hence information about topology and resource availability are required for the specific layer to which the connection belongs. The topology and resource availability information required by a path computation element in the client layer is quite distinct from that required by a path computation element in the server layer network. Hence, the actual server layer traffic engineering links are of no importance for the client layer network. In fact, it can be desirable to block their advertisements into the client TE domain by the border nodes. (draft-ali-te-metric-recording): Moreover there are many scenarios in which Traffic Engineering (TE) metrics such as cost, latency and latency variation associated with a Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched Path (LSP) are not available to the ingress (edge node) and egress nodes. 6. Use cases + L1VPN (from draft-fedyk) + IP/MPLS Offloading with ENNI automation (from draft-enni) + Service Optimization and Restoration in Multi-layer networks (from draft enni) + Use of PCE and VNTM in Multi-layer Network Operation (from draft enni) 7. Compatibility 8. Security Considerations Ceccarelli, et al. Expires April 25, 2013 [Page 14] Internet-Draft Overlay model framework October 2012 9. IANA Considerations 10. Contributors George Swallow, Cisco System Zafar Ali, Cisco System 11. Acknowledgements 12. References 12.1. Normative References [E-NNI] Beeram V.,Bryskin I.,Doonan W.,Drake J.,Grammel G.,Paul M.,Kunze R.,Armbruster F.,de Dios O., "Generalized Multiprotocol Label Switching (GMPLS) External Network Network Interface (E-NNI): Virtual Link Enhancements for the Overlay Model", July 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User- Network Interface (UNI): Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. 12.2. Informative References Authors' Addresses Daniele Ceccarelli (editor) Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Ceccarelli, et al. Expires April 25, 2013 [Page 15] Internet-Draft Overlay model framework October 2012 Igor Bryskin ADVA Optical Networking Email: ibryskin@advaoptical.com Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net John Drake Juniper Networks Email: jdrake@juniper.net Cyril Margaria Nokia Siemens Networks Email: cyril.margaria@nsn.com Ceccarelli, et al. Expires April 25, 2013 [Page 16]