Multi-domain network integration framework in the context of overlay model
draft-many-ccamp-gmpls-overlay-model-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Daniele Ceccarelli , Igor Bryskin , Vishnu Pavan Beeram , John Drake | ||
| Last updated | 2012-10-15 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-many-ccamp-gmpls-overlay-model-00
CCAMP Working Group D. Ceccarelli, Ed.
Internet-Draft Ericsson
Intended status: Informational I. Bryskin
Expires: April 15, 2013 ADVA Optical Networking
V. Beeram
J. Drake
Juniper Networks
October 12, 2012
Multi-domain network integration framework in the context of overlay
model
draft-many-ccamp-gmpls-overlay-model-00
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, 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 15, 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Ceccarelli, et al. Expires April 15, 2013 [Page 1]
Internet-Draft Overlay model framework October 2012
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
4. Signaling: Info passed from Edge Network to Core network . . . 8
5. routing: Info passed from Core Network to Edge network . . . . 9
6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Ceccarelli, et al. Expires April 15, 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 15, 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 15, 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 15, 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
[TBD]
+ properties
+ options
+ advantages
+ disadvantages
[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
Ceccarelli, et al. Expires April 15, 2013 [Page 6]
Internet-Draft Overlay model framework October 2012
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
recording
3.2. GMPLS E-NNI
[TBD]
+ properties
+ options
+ advantages
+ disadvantages
[statements]:
- 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.
- 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
Ceccarelli, et al. Expires April 15, 2013 [Page 7]
Internet-Draft Overlay model framework October 2012
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
+ Exclude Route(draft-ali-xro-lsp0subobject):
+ Exclude Route(RFC4874)
Ceccarelli, et al. Expires April 15, 2013 [Page 8]
Internet-Draft Overlay model framework October 2012
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
9. IANA Considerations
10. Contributors
Ceccarelli, et al. Expires April 15, 2013 [Page 9]
Internet-Draft Overlay model framework October 2012
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
Igor Bryskin
ADVA Optical Networking
Email: ibryskin@advaoptical.com
Ceccarelli, et al. Expires April 15, 2013 [Page 10]
Internet-Draft Overlay model framework October 2012
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
John Drake
Juniper Networks
Email: jdrake@juniper.net
Ceccarelli, et al. Expires April 15, 2013 [Page 11]