Internet DRAFT - draft-many-ccamp-gmpls-overlay-model
draft-many-ccamp-gmpls-overlay-model
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
------------------
=====
<S4-S3> 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]
