CCAMP Working Group D. Ceccarelli
Internet-Draft Ericsson
Intended status: Informational O. Gonzalez de Dios
Expires: January 12, 2014 Telefonica I+D
F. Zhang
X. Zhang
Huawei Technologies
July 11, 2013
Use cases for operating networks in the overlay model context
draft-ceccadedios-ccamp-overlay-use-cases-01
Abstract
This document defines a set of use cases for operating networks in
the overlay model context through the Generalized Multiprotocol Label
Switching (GMPLS) overlay interfaces.
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 January 12, 2014.
Copyright Notice
Copyright (c) 2013 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
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
Ceccarelli, et al. Expires January 12, 2014 [Page 1]
Internet-Draft Overlay model use cases July 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Variants of UNI interface . . . . . . . . . . . . . . . . . . 6
3.1. UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. UNI example . . . . . . . . . . . . . . . . . . . . . 7
3.2. ONI . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Routing info over the ONI . . . . . . . . . . . . . . 9
4. Hybrid Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Adding the PCEP to the UNI . . . . . . . . . . . . . . . . . . 11
5.1. Edge-node to core-node PCEP interface . . . . . . . . . . 11
5.2. PCEP and colored UNI . . . . . . . . . . . . . . . . . . . 13
5.3. Using PCEP to obtain TE reachability info . . . . . . . . 13
6. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Use case P1 - Local Trigger . . . . . . . . . . . . . . . 14
6.2. Use case P2 - Remote Signaling . . . . . . . . . . . . . . 14
6.3. Use case P3 - Provisioning with requirements over the
UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Use case P4 - Provisioning with requirements and
collection request over the UNI . . . . . . . . . . . . . 17
6.5. Use case P5 - Advertisement of collected metrics in
the client layer . . . . . . . . . . . . . . . . . . . . . 17
6.6. Use case P6 - Provisioning with requirements over the
ONI . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Use case P7 - Dual homing . . . . . . . . . . . . . . . . 18
7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Use case R1 - Segment Recovery - Single homing . . . . . . 19
7.2. Use case R2 - Local recovery - Dual Homing - Single
overlay node . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Use case R3 -End to end Recovery - Dual homing -
Double overlay node . . . . . . . . . . . . . . . . . . . 20
7.4. Use case R4 - Combination of client protection and
server restoration . . . . . . . . . . . . . . . . . . . . 21
8. Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Use case O1 - . . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
13. References to be added . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . . 24
Ceccarelli, et al. Expires January 12, 2014 [Page 2]
Internet-Draft Overlay model use cases July 2013
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Ceccarelli, et al. Expires January 12, 2014 [Page 3]
Internet-Draft Overlay model use cases July 2013
1. Introduction
The GMPLS overlay model [RFC 4208] specifies a client-server
relationship between networks where client and server layers are
managed as separate domains because of trustiness, scalability and
operational issue. By means of procedures from the GMPLS protocol
suite it is possible to build a topology in the client (overlay)
network from Traffic Engineering paths in the server network. In
this context, the UNI (User to Network Interface) is the demarcation
point between networks. It is a boundary where policies,
administrative and confidentiality issues apply that limit the
exchange of information.
This GMPLS overlay model supports a wide variety of network
scenarios. The packet over optical scenario is probably the most
popular example where the overlay model applies.
In order to exploit the full potential of client/server network
interworking in the overlay model, it may be desirable to know in
advance whether is it feasible or not to connect two client network
nodes [INTERCON-TE]. This requires to have a certain amount of TE
information of the server network in the client network. This need
not be the full set of TE information available within each network,
but does need to express the potential of providing TE connectivity.
This subset of TE information is called TE reachability information.
Reachability can be classified according to the available
information:
- Non-qualified reachability: The most basic form of TE
reachability is just the information of whether is it physically
feasible to connect two nodes. Thus, Non-qualified reachability
is the ability to be able to connect one end point to another.
- Qualified reachability: In addition to knowing of whether is it
physically feasible to connect two nodes, the qualified
reachability information indicates metrics of the potential
connection. This metric can be a cost, a service metric (delay),
bandwidth, etc.
- Reachability with associated Potential Virtual Link: In this
case, the client node, in addition to have the information of the
feasibility of reaching a given destination, it has the
information of a possible path, that can be established at any
time through UNI signalling. This possible path may have been
pre-computed in advance and may contain the explicit path (e.g.
ERO). Thus, client layer topology could be richened with this
potential virtual TE link information.
Ceccarelli, et al. Expires January 12, 2014 [Page 4]
Internet-Draft Overlay model use cases July 2013
Current standard GMPLS UNI [RFC 4208] is focused on signaling and
extensions to the GMPLS UNI [RFC4208] are being proposed to gather a
tighter integration between the client packet layer and the server
optical one. Also, new elements, like the Path Computation element
(PCE), have become more popular and may also play a role in the
overlay context. In order to understand what are the requirements
that need to be fulfilled, it is necessary to understand current use
cases, that is, what are the network operators expecting the UNI to
do.
The first group of uses cases of the overlay model is related to the
automatic provisioning, by which the client (overlay) network is able
to set-up a connection through the server network. The second group
of use cases is related to the enhancement of the recovery mechanism
by a higher coordination of overlay and server networks.
Summing up, the goal of this document is to overview the network
scenarios where the overlay model applies and analyze the most
interesting aspects of the use cases that fall under the above
definitions, with particular focus on signaling, exchange of info,
operations, path computation and L1VPN aspects.
2. Terminology
The following terms are used within the document:
- Edge node [RFC4208]: node of the client domain belonging to the
overlay network, i.e. nodes with at least one interface connected
to the server domain.
- Core node [RFC4208]: node of the server domain.
- Access link: link between core node and edge node. It is the
link where the UNI is usually implemented.
- Remote node: node in the client domain which has no direct
access to the server domain but can reach it through an edge node
in its same administrative domain.
- Local trigger: LSP setup request issued to an edge node. It
triggers the setup of a client layer FA through the server domain
via a UNI interface.
- Remote trigger: LSP setup request issued to a remote node. It
triggers the setup of a client layer LSP which, upon reaching an
edge node, will use an FA through the server domain dynamically
provided via an UNI interface.
Ceccarelli, et al. Expires January 12, 2014 [Page 5]
Internet-Draft Overlay model use cases July 2013
3. Variants of UNI interface
[RFC4208] defines the GMPLS UNI as an overlay interface allowing for
the exchange of both routing and signaling messages between a client
and a server domain. At that time only signaling extensions and
procedures for the UNI interface were defined but since them a lot of
RSVP-TE extensions have been defined (e.g. [LSP-DIV][TE-REC]).
In this section a tassonomy of different variants of UNI interfaces
is provided.
3.1. UNI
GMPLS UNI defined in [RFC4208] allows the exchange of RSVP-TE Path
messages between edge and core nodes including the Explicit Route
Object (ERO) or Record Route Object (RRO). This allows for the
explicit indication of the path (or part of it) to choose in the
server domain or the recording of the nodes and links chosen
respectively.
Subsequently new requirements have been added to the exchange of
messages between edge and core nodes. In the message flow from edge
to core nodes it is desirable to define a number of path computation
constraints that the server domain needs to consider when providing a
path that will be used as connection between two edge nodes. An
example of path computation constraints consists of: SRLG diversity,
max latency, max number of hops, etc. Encoding extensions for adding
constraints to the server domain path computation are defined in
[UNI-PLUS] and [LSP-DIV].
Similarly it is desirable that the core nodes are able to provide the
edge nodes with the parameters qualifying the path provided. Such
set of parameters is the same identified above and encoding
extensions for its collection are defined in [TE-REC] and [SRLG-
COLL].
RSVP-TE extensions are obviously inherited by the UNI interface,
which has significantly been augmented with respect to the RFC4208
version.
In the overlay model applied to the packet-opto environment the UNI
can be implemented over grey or colored interfaces. In the former
case the transponder is placed on the RROADM and the traffic from the
router to the RROADM has no G.709 framing, while in the latter the
transponder is moved on the router and the traffic injected into the
WDM domain is G.709 framed and managed as an alien lambda. From a
procedure point of view there is no difference between the grey and
the colored UNI, what is different is the type of information that
Ceccarelli, et al. Expires January 12, 2014 [Page 6]
Internet-Draft Overlay model use cases July 2013
the WDM PCE need to be provided with in orded to compute a path in
the WDM domain but check its feasibility from router to router.
For applicability considerations regarding the GMPLS UNI please refer
to [UNI-APP]
3.1.1. UNI example
This section provides an example of how SRLGs, latency and other
types of parameters can be used in the edge node to core node
direction as path computation constraints and in the reverse
direction from core node to edge node as path qualifiers. The
example is applied to a packet-opto environment.
In the reference network below, suppose that router 1 wants RROADM A
to provide a path between A and G with max unidirectional latency
20ms and SRLG different from (37;52). Such parameters are passed to
A via the RSVP-TE Path message.
PATH (max latency 20, SRLG !(37;52))
+---+ ----> /-\ /-\ /-\ +---+
| 1 |******( A )-----( B )----------( C )*********| 3 |
+---+ \-/ \-/\ \-/ +---+
| \ / | \ / \
| \ / | \ / \
| \ / | \ / \
| \ | \ / \
| / \ | \ / \
+---+ /-\ / \/-\ /-\ /-\ +---+
| 2 |******( D )-----( E )---( F )---------( G )*****| 4 |
+---+ \-/ \-/ \-/ \-/ +---+
Figure 1: Path computation constraints
Node A performs a constrained path computation in the optical domain
(A-B-C-G) and provides 1 (via the RSVP-TE RESV message) with the
parameters qualifying the provided path e.g. max latency 12ms and
SRLG (11,55).
Ceccarelli, et al. Expires January 12, 2014 [Page 7]
Internet-Draft Overlay model use cases July 2013
RESV (latency 12, SRLG (11;55)
+---+ <---- /-\ /-\ /-\ +---+
| 1 |******( A )=====( B )==========( C )*********| 3 |
+---+ \-/ \-/\ \-/ +---+
| \ / | \ / =
| \ / | \ / =
| \ / | \ / =
| \ | \ / =
| / \ | \ / =
+---+ /-\ / \/-\ /-\ /-\ +---+
| 2 |******( D )-----( E )---( F )---------( G )*****| 4 |
+---+ \-/ \-/ \-/ \-/ +---+
Figure 2: Real network topology
3.2. ONI
A different variant of GMPLS UNI interface can be implemented within
the overlay model context. It foresees adding some TE (Traffic
Engineering) topological information exchange between edge and core
nodes. We use the term ONI (Overlay Network Interface) to identify
this variant of UNI interface with such capabilities.
The ONI foresees the definition of a virtual topology in the server
layer (arbitrarily configured by the network operator) which is
exported by each core border node to its peering edge node by means
of a routing protocol (e.g. OSPF-TE, BGP-LS). Such virtual topology
comprises a mix of potential virtual TE-links [RFC4847] and virtual
nodes.
A virtual TE-link, as defined in RFC4847, is a provider network
Traffic Engineering (TE) link advertised to customers in routing
information for purposes that include path computation. We introduce
the term potential virtual TE-link to indicate those virtual TE-links
whose resources are not necessarily reserved or committed in the
server layer network.
A potential virtual TE link is advertised via the ONI as a real TE
link and hence contributes to augmenting the client layer topology.
Moreover it does not require the allocation of resources in the
server layer until it is really used thus allowing the mutually
exclusive sharing of server layer network resources with other
potential Virtual TE Links.
On the other side a virtual node is a collection of zero or more
provider network domain nodes that are collectively represented to
the clients as a single node that exists in the customer layer
Ceccarelli, et al. Expires January 12, 2014 [Page 8]
Internet-Draft Overlay model use cases July 2013
network and is capable of terminating of access, inter-domain and
virtual links. (a virtual node can correspond 1:1 to a physical node,
to a part of it or to a set of nodes).
As per the UNI, we define two variations of ONI for the packet-opto
scenario, namely the ONI when we refer to grey interfaces (i.e.
transponder on the RROADM) and ONI++ when referring to colored
interfaces (i.e. transponder on the router).
3.2.1. Routing info over the ONI
The following reference network in an IPoWDM environment is used to
depict what kind of information needs to be advertised to the edge
nodes in order to augment the client layer topology.
+---+ /-\ /-\ /-\ +---+
| 1 |******( A )-----( B )----------( C )*********| 3 |
+---+ \-/ \-/\ \-/ +---+
| \ / | \ / \
| \ / | \ / \
| \ / | \ / \
| \ | \ / \
| / \ | \ / \
+---+ /-\ / \/-\ /-\ /-\ +---+
| 2 |******( D )-----( E )---( F )---------( G )*****| 4 |
+---+ \-/ \-/ \-/ \-/ +---+
Figure 3: Real network topology
Where:
+---+
| 1 | = Edge node ********* = Access Link (UNI link)
+---+
/-\
( A ) = Core node --------- = Core domain real link
\-/
Suppose that the network operator decides to let client network see
two potential virtual TE-links, one between A and C and the other
between D and G. Figure below show the potential virtual TE-links on
Ceccarelli, et al. Expires January 12, 2014 [Page 9]
Internet-Draft Overlay model use cases July 2013
the left and corresponding real topology on the right.
+-+ /-\ /-\ +-+ | +-+ /-\ /-\ /-\ +-+
|1|**( A )+++++++++++( C )**|3| | |1|**( A )+++( B )+++( C )**|3|
+-+ \-/ \-/ +-+ | +-+ \-/ \-/#####\-/ +-+
| # #
| # #
| # #
| # #
| # #
+-+ /-\ /-\ +-+ | +-+ /-\ /-\ /-\ +-+
|2|**( D )###########( F )**|4| | |2|**( D ) ( E ) ( F )**|4|
+-+ \-/ \-/ +-+ | +-+ \-/ \-/ \-/ +-+
+++ = Pot. Virt. TE-link 1 | +++ = Real path of Pot.V.TE-link 1
### = Pot. Virt. TE-link 2 | ### = Real path of Pot.V.TE-link 2
Figure 4: Virtual network topology
From the above figure it is possible to see that the edge nodes, in
order to be able to compute a path, need to know the following:
- Access links: availability and TE parameters
- Potential virtual TE-links: availability, TE parameters,
diversity, constraints (e.g. latency, packet loss)
- Virtual nodes: (in figure above a 1 to 1 relationship between
real and virtual nodes is assumed) availability, connectivity
matrix, TE parameters, diversity, constraints (in those cases
where a virtual node is composed of 2 or more real nodes)
More details on potential virtual TE links diversity can be found at
[MELG].
4. Hybrid Nodes
The overlay model and interfaces can be applied also to hybrid nodes
[RFC5212], where it is possible to have different control plane
instances in the client and server domain and keep on exploiting the
advantages of managing the domains separately without loosing the
capability of making them tightly interwork.
Ceccarelli, et al. Expires January 12, 2014 [Page 10]
Internet-Draft Overlay model use cases July 2013
5. Adding the PCEP to the UNI
In the GMPLS overlay model, the edge nodes do not participate in the
routing instance of the core network. This means that the overlay
network is not aware of the details (topology and TE information) of
the core network. Thus, it is generally assumed that, in the case of
a UNI request, the routing is performed in the core network.
The operator is able to include a set of constraints that have impact
on the routing that will be performed in the core network in two
different ways. One is to enrich RSVP-TE to include such constraints
(please see above), and the other one is use the well-defined PCEP
protocol.
The main advantage of using the PCEP interface is that the semantics
for the different queries are well defined. Moreover, in case
confidentiality and trustiness is an issue, the Path Key mechanism
can be used in the answers to hide the details of the path.
Different possible scenarios are shown bellow.
5.1. Edge-node to core-node PCEP interface
The first scenario foresees the provisioning of a PCEP interface from
the core nodes to the edge nodes. Such interface is reachable from
the same interfaces used for the exchange of UNI signaling messages.
The path computation in the server domain can be centralized or
distributed. In the former scenario the core node acts as a proxy
between the PCC on the edge node and the PCE as shown in figure
below.
Ceccarelli, et al. Expires January 12, 2014 [Page 11]
Internet-Draft Overlay model use cases July 2013
+------+
PCEP |Server|
+------------>|Domain|
| |PCE |
+---+ PCEP +-----+ +------+
|PCC|----->|Proxy|
+---+ |-----| /-\ /-\ +---+
|EN |******| CN |-----(CN )------(CN )****|EN |
+---+ \ - / \-/ \-/ +---+
| | |
| | |
| | |
| | |
+---+ /-\ /-\ /-\ +---+
|EN |******(CN )------(CN )------(CN )*****|EN |
+---+ \-/ \-/ \-/ +---+
Figure 5: PCEP proxy on core node
On the other hand, when the path computation in the server domain is
performed in a distributed way, the PCEP interface can be exported by
the core nodes so to allow the edge node issue path computation
queries. See figure below.
+---+ PCEP +-----+
|PCC|----->| PCE |
+---+ |-----| /-\ /-\ +---+
|EN |******| CN |-----(CN )------(CN )****|EN |
+---+ \ - / \-/ \-/ +---+
| | |
| | |
| | |
| | |
+---+ /-\ /-\ /-\ +---+
|EN |******(CN )------(CN )------(CN )*****|EN |
+---+ \-/ \-/ \-/ +---+
Figure 6: PCEP interface between EN and CN
In those cases where the addressing space is common between the
client and the server layer, and hence with the PCE, it is also
possible to have the PCC on the client layer directly speaking with
the server domain PCE as shown in figure below.
Ceccarelli, et al. Expires January 12, 2014 [Page 12]
Internet-Draft Overlay model use cases July 2013
+------+
PCEP |Server|
+------------------------->|Domain|
| |PCE |
+---+ +------+
|PCC|
+---+ /-\ /-\ /-\ +---+
|EN |******(CN)--------(CN )------(CN )****|EN |
+---+ \-/ \-/ \-/ +---+
| | |
| | |
| | |
| | |
+---+ /-\ /-\ /-\ +---+
|EN |******(CN )------(CN )------(CN )*****|EN |
+---+ \-/ \-/ \-/ +---+
Figure 7: PCE and PCC direct connection
5.2. PCEP and colored UNI
TBD
5.3. Using PCEP to obtain TE reachability info
Although the overlay network does not participate in the routing
instance of the server network, RFC 4208 allows TE reachability to be
exchanged between both overlay and server networks. TE
reachability,as defined in [INTERCON-TE], is the ability to reach a
specific address along a TE path. In the overlay context, TE
reachibilty indicates if it is possible to reach from one node of the
overlay network to another one through the server network. Also, TE
reachability can indicate some TE metrics of the possible paths
metrics, hop count, available bandwidth, delay, shared risk.
The PCEP interface can be used at the UNI border to query from
overlay network to server network about the possible paths between
nodes. The answers do not need to include a full detailed ERO, but
just a collection of the desired metrics and, either a path key, or
an ERO with just the end-points.
6. Provisioning
Two different use cases can be identified for path provisioning
depending on where the setup trigger is issued. They will be called
Local and Remote Trigger in the following. Further details regarding
Ceccarelli, et al. Expires January 12, 2014 [Page 13]
Internet-Draft Overlay model use cases July 2013
different provisioning models over the UNI can be found in [UNI-APP].
What described below is in addition to the simple provisioning use
case without constraints defined in [RFC4208].
6.1. Use case P1 - Local Trigger
Local Trigger is the use case defined in RFC4208, where a setup
trigger is issued to one of the edge nodes belonging to the overlay
network, i.e. directly connected to the UNI.
1.Trigger (with constraints)
| 2. Setup
V ------------>
+--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+
|R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7|
+--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+
\ / | \ / | \ | \ /
\ / | \ / | \ | \ /
\ / | \ / | \ | \ /
\ +--+ / | \ | \ | \ +--+/
|R4| | / \ | \| |R8|
+--+ /-\ / \/-\ /-\ +--+
3.Advertisement ( D )-----( E )---( F ) 3.Advertisement
\-/ \-/ \-/
*** = overlay interfaces
Figure 8: Local trigger
As it is possible to see in the figure above, a trigger is issued on
R3 (edge node) for starting the setup request procedure over the UNI
interface (R3-A). Such trigger might include an arbitrary set of
constraints for the path computation in the optical domain. Once the
optical LSP is setup and an adjacency in the packet layer between R3
and R5 is created, it is advertised in the rest of the packet layer
and used by the signaling protocol (e.g. LDP) for setting up end-to-
end (e.g. from R1 to R7) packet LSPs.
6.2. Use case P2 - Remote Signaling
A second use case consists on the utilization of a connection
oriented (e.g. RSVP-TE) signaling protocol in the packet domain that
allows issuing the setup trigger directly on the end nodes of the
packet domain and using the RSVP-TE message for triggering the setup
of the LSP in the optical domain.
Ceccarelli, et al. Expires January 12, 2014 [Page 14]
Internet-Draft Overlay model use cases July 2013
1.Trigger (with constraints)
| 2. Setup
V -------------> |------------>|
|------>----------------->------->|
|<-----<-----------------<--------|
<--------------------------------------------------|-------------|
+--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+
|R1|---|R2|---|R3|****( A )-----( B )---( C )*****|R5|---|R6|---|R7|
+--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+
\ / | \ / | \ | \ /
\ / | \ / | \ | \ /
\ / | \ / | \ | \ /
\ +--+ / | \ | \ | \ +--+/
|R4| | / \ | \| |R8|
+--+ /-\ / \/-\ /-\ +--+
( D )-----( E )---( F )
\-/ \-/ \-/
Figure 9: Local trigger
The utilization of the remote trigger allows for a strict control of
the resources that will be used for the setup of the end to end path.
In particular, two further approaches are possible when using the
remote trigger: RSVP-TE or BGP approach. In the case of RSVP-TE it
is possible to exploit the capabilities of the protocol of signaling
LSPs across multiple domains and indicate in the ERO (explicit route
object) the resources that need to be included in the path. It is
possible to indicate a strict ERO (i.e. all the indicated resources
and only those ones must be used) or a loose ERO (i.e. at least the
indicated resources must be used but the PCEs of the different
domains decide autonomously how to fill the gaps in the ERO.
6.3. Use case P3 - Provisioning with requirements over the UNI
This use case applies to both the local and remote trigger scenarios
and describes how it is possible for the client layer to ask for a
connection in the server layer with some constraints. An example of
the constraints that can be applied to the path computation in the
server layer consists of the following criteria:
+ Diversity: it is possible to indicate the resources must or
should be avoided during the path computation by means of the
Exclude Router Object (XRO) [RFC4874], the Explicit Exclusion
Route Subobject (EXRS) [RFC4874] and the LSP subobject [LSP-DIV].
Such resources consists on:
Ceccarelli, et al. Expires January 12, 2014 [Page 15]
Internet-Draft Overlay model use cases July 2013
-IPv4 prefix [RFC4874]
-IPv6 prefix [RFC4874]
-Unnumbered Interface ID [RFC4874]
-Autonomous system number [RFC4874]
-SRLG [RFC4874]
-IPv4 P2P subobject [LSP-DIV]
-IPv6 P2P subobject [LSP-DIV]
+ Latency: max delay introduced by the server layer LSP [OF-TEMB]
+ Latency variation: max latency variation allowed for the server
layer LSP [OF-TEMB]
+ Cost: max cost allowed for the server layer LSP [OF-TEMB]
The overlay Edge Node can include into the RSVP-TE Path message an
arbitrary number of path computation constraints for the provisioning
of the LSP in the server domain. In figure below and example is
shown using as path computation constraints: (i) max latency should
be 20ms and (ii) SRLG must be different from (A;B).
PATH (max latency 20-SHOULD, SRLG !(A;B)-MUST)
+---+ ----> /-\ /-\ /-\ +---+
| 1 |******( A )-----( B )----------( C )*********| 3 |
+---+ \-/ \-/\ \-/ +---+
| \ / | \ / \
| \ / | \ / \
| \ / | \ / \
| \ | \ / \
| / \ | \ / \
+---+ /-\ / \/-\ /-\ /-\ +---+
| 2 |******( D )-----( E )---( F )---------( G )*****| 4 |
+---+ \-/ \-/ \-/ \-/ +---+
Figure 10: Use Case P3 - provisioning with requirements
If the path computation in the server domain is able to provide an
LSP meeting the requirements (at least the must ones) such LSP is
established and a RESV message is returned to the Edge node,
otherwise an error message (PattErr) is returned.
Ceccarelli, et al. Expires January 12, 2014 [Page 16]
Internet-Draft Overlay model use cases July 2013
6.4. Use case P4 - Provisioning with requirements and collection
request over the UNI
This use case is an extension of Use case P3. In addition to the
path request with path computation constraints, the client layer is
also allowed to request for the collection in the server domain of
the effective values of the parameters indicated as path computation
constraints. The collection of such parameters is indicated via
dedicated flags in the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES in
the Path Message. Flags defined are:
- Cost collection flag [TE-REC]
- Latency collection flag [TE-REC]
- Latency Variation collection flag [TE-REC]
- SRLG collection flag [SRLG-COLL]
In the scenario depicted in figure Figure 10 a request with
constraints on max latency and SRLG diversity might be issued
together with the request of collecting e.g. the effective SRLGs of
the provided path. Collected parameters are returned to the overlay
edge node via the Record Route Object (RRO) in the RESV message.
6.5. Use case P5 - Advertisement of collected metrics in the client
layer
In the case of local trigger, that is when a forwarding adjacency
(FA) is created between two nodes in the client domain by means of an
LPS in the server domain, it is desirable to advertise the
characteristics of such FA in the client domain so that an informed
path computation in the client layer can be performed.
Interior Gateway Protocol (IGP) extensions for the advertisement of
the TE metrics characterizing such forwarding adjacencies have been
defined for IS-IS [ISIS-TEMET] and OSPF-TE [OSPF-TEMET].
It is also possible to perform such advertisement by means of BGP-LS,
where the collected data are sent to the route reflector and then
forwarded to all the BGP speakers in the different client domains.
6.6. Use case P6 - Provisioning with requirements over the ONI
In the case of ONI/ONI++ each overlay edge node is provided with the
overlay topology of the server domain as indicated in section
Section 3.2. When a trigger is receiver by the edge node (local or
remote), it is able to choose among the different available paths
Ceccarelli, et al. Expires January 12, 2014 [Page 17]
Internet-Draft Overlay model use cases July 2013
depending on which one meets the constraints included into the
trigger. When a path is selected, the signaling procedure occurs
accordingly with a standard RSVP-TE signaling procedure including a
strict (or loose) ERO. For more details please see [ENNI].
6.7. Use case P7 - Dual homing
A quite common case is the need for provisioning two (or more)
optical paths with different ingress and egress nodes (i.e. different
CNs) with diversity constraints. This is needed to provide two
totally disjoint paths in the client layer without any kind of single
point of failure (e.g. a single UNI link or a single edge node) in
order to create protection schemes in the packet layer like e.g. 1+1
protection.
In this case some sort of info exchange in the client domain is
needed and can be provided in two ways:
- Coordination between 1 and 3
- Coordination between 2-1 and 2-3 [UNI EXT]
In both cases node 1 is supposed to ask the optical domain to provide
a path (e.g. restorable [RFC4873]) and collect its SRLGs, then pass
such SRLGs info to node 3 (directly or via 2). Hence node 3 will ask
the optical domain to provide a path (e.g. restorable) avoiding the
given SRLGs.
SRLG:27
+---+ /-\SRLG:21/-\ SRLG:36 /-\ +---+
++| 1 |++++++( A )+++++( B )++++++++( C )+++++++++| 4 |++
+ +---+ \-/ \-/\ / \-/\ +---+ +
+ | | \ / \ / \ +
+---+ |SRLG:(21,| \/-\/ \/-\/ \ +---+
| 2 | |27,36) | ( D )------( E ) \ | 5 |
+---+ | | \-/ \-/ \ +---+
# V | / \ \ \ #
# +---+ /-\ / \/-\ /-\ /-\ +---+ #
###| 3 |######( F )#####( G )###( H )########( H )##| 6 |##
+---+ P \-/ P \-/ P \-/ P \-/ +---+
+++ = working path ### = protection path
Figure 11: Use Case P7 - Dual homing
As per previous use cases it is possible to either provide the path
between 1 and 4, collect the SRLGs, provide the path between 3 and 6
Ceccarelli, et al. Expires January 12, 2014 [Page 18]
Internet-Draft Overlay model use cases July 2013
with SRLG diversity constraints and than let the packet domain use
those two packet layer adjacencies or have 2 asking 1 and 3 to
respectively set up 1-4 and 3-6.
Whenever one of the paths is restored in the optical domain (e.g.
B-C fails and the path is restored using A-B-E-C), an SRLG collection
procedure (by 1) and exchange (to F) is needed so that a possible
restoration of the protection path would avoid the new SRLGs of
working path. Please see use case R4.
7. Recovery
7.1. Use case R1 - Segment Recovery - Single homing
This is one of the simplest recovery scenarios, where each overlay
node has a single UNI interface available on the overlay nodes and
hence only the server layer is in charge of restoring or protecting
the traffic within its domains boundaries. As it is possible to see
in figure below the client layer is able to recover from failures
within the server domain.
+--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+
|R1|---|R2|---|R3|****( A )--X--( B )---( C )*****|R5|---|R6|---|R7|
+--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+
| \ / | \ |
| \ / | \ |
| \ / | \ |
| \ | \ |
| / \ | \|
/-\ / \/-\ /-\
( D )-----( E )---( F )
\-/ \-/ \-/
Figure 12: Use case R1 - Segment Recovery - Single homing
This kind of scenario is extremely cheap in terms of resource
utilization but has some limitations due to a high number of single
points of failures which, in case of unavailability, prevent any type
of recovery attempt. The single points of failure are: the overlay
nodes (R3 and R5), the UNI links (R3-A and C-R5) and the server
domain border nodes (A and C). In the following sections higher
degrees of reliability are provided.
Ceccarelli, et al. Expires January 12, 2014 [Page 19]
Internet-Draft Overlay model use cases July 2013
7.2. Use case R2 - Local recovery - Dual Homing - Single overlay node
In this use case it is possible to combine local recovery in the
overlay nodes (e.g. Fast Rerouting) with restoration or protection
in the optical domain so to be able to react to failures not only in
the client domain but also affecting the server layer border nodes (A
and C) and the UNI links (R3-A and R5-C). The number of single
points of failure is hence significantly reduced to just the overlay
nodes (R3 and R5).
+--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+
|R1|---|R2|---|R3|****( A )--X--( B )---( C )**X**|R5|---|R6|---|R7|
+--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+
* | \ / | \ | *
* | \ / | \ | *
* | \ / | \ | *
* | \ | \ | *
* | / \ | \| *
* /-\ / \/-\ /-\*
( D )-----( E )---( F )
\-/ \-/ \-/
Figure 13: Use case R2 - Local recovery - Dual Homing - Single
overlay node
7.3. Use case R3 -End to end Recovery - Dual homing - Double overlay
node
This use case focuses on recovery just in the client layer, no
recovery is requested to the server layer but just the provisioning
of LSPs with requirements (in this case diversity).
The provisioning of the working path occurs like the provisioning of
LSP over the UNI with remote trigger and with the collection of SRLGs
enabled. Once that the optical LSP supporting the working client LSP
is setup (A-B-C), the SRLGs in the optical domain are collected and
passed to the overlay node (R3) which forwards them to the ingress
node (R1) in the reverse path of the signaling process of the working
LSP (i.e. RSVP-TE Resv Message).
Once that R1 is provided with the SRLGs in the optical domains, it is
able to issue the signaling of the protection LSP indicating in a
loose ERO R5 and R7 as loose hops and the SRLG diversity in the ERO
expansions between them. This will lead in the provisioning of a
path in the photonic domain diverse from the previous one (S2-S4-S6)
and hence two total diverse end to end paths. In this case the
Ceccarelli, et al. Expires January 12, 2014 [Page 20]
Internet-Draft Overlay model use cases July 2013
network will be able to recover to a single failure in any part of
the network without any single point of failure.
+--+ +--+ +--+ /-\ /-\ /-\ +--+ +--+ +--+
|R1|---|R2|---|R3|****( A )--X--( B )---( C )**X**|R6|---|R7|---|R8|
+--+ +--+ +--+ \-/ \-/\ \-/ +--+ +--+ +--+
\ | \ / | \ | /
\ | \ / | \ | /
\ | \ / | \ | /
\ | \ | \ | /
\ | / \ | \| /
+--+ +--+ /-\ / \/-\ /-\ +--+ +---+
|R4|---|R5|****( D )-----( E )---( F )**X**|R9|---|R10|
+--+ +--+ \-/ \-/ \-/ +--+ +---+
Figure 14: Use case R3 -End to end Recovery - Dual homing - Double
overlay node
7.4. Use case R4 - Combination of client protection and server
restoration
This is the most interesting use case when the overlay model is
applied to the packet/opto scenario. The packet protection and
optical restoration allows for a fast recovery of the traffic upon a
failure in the network, while the restoration in the optical domain
allows for always providing the packet layer with two available path
against an arbitrarily high number of failure in the optical network
(the number of failures depend on the meshing degree of the photonic
network).
Moreover the exchange of SRLGs over the UNI interface (please see
Provisioning use cases) makes sure that the optical path used for the
working branch of the packet protection and the optical path used for
the protection branch of the packet protection do not share any
resource and hence that a single failure in the optical domain does
not cause any traffic hit; i.e. traffic can be recovered with packet
protection time (tens of ms) instead of photonics restoration time
(tens of s).
The SRLG collecgion procedure is pretty simple during the
provisioning phase, but more complicated when one of the paths fail
and is restored.
In figure below an example is considered where a protection is
provided in the client layer where the working path is setup along
path (2-1-A-C-4-5) and its protection path along (2-3-F-H-G-6-5).
Ceccarelli, et al. Expires January 12, 2014 [Page 21]
Internet-Draft Overlay model use cases July 2013
After the setup of the optical path between A and C (A-B-C), the
SRLGs of such path are collected and the overlay edge node 3 can ask
F for the setup of a path between F and H avoiding such SRLGs. This
ensures that a single failure in the optical domain will not affect
both the W and P.
+---+ /-\ /-\ /-\ +---+
++| 1 |++++++( A )+++++( B )++++++++( C )+++++++++| 4 |++
+ +---+ \-/ \-/\ / \-/\ +---+ +
+ | \ / \ / \ +
+---+ | \/-\/ \/-\/ \ +---+
| 2 | | ( D )------( E ) \ | 5 |
+---+ | \-/ \-/ \ +---+
# | / \ \ \ #
# +---+ /-\ / \/-\ /-\ /-\ +---+ #
###| 3 |######( F )#####( G )###( H )########( H )##| 6 |##
+---+ \-/ \-/ \-/ \-/ +---+
+++ = working path ### = protection path
Figure 15: Use Case R4 - Setup of paths in full diversity
In order to guarantee that different SRLGs will always be used for W
and P it is necessary to perform two different steps after the
provisioning of the two LSPs:
1. Each ingress node of the server domain paths (namely A and F)
must be informed that in case of restoration the path computation
must avoid the *actual* SRLG of the other path
2. Every time that either of the server domain paths is restored,
the collection of SRLGs must be performed and communicated to the
ingress node of the other LSP.
Ceccarelli, et al. Expires January 12, 2014 [Page 22]
Internet-Draft Overlay model use cases July 2013
+---+ /-\ /-\ /-\ +---+
++| 1 |++++++( A )+++++( B )--- X --( C )+++++++++| 4 |++
+ +---+ \-/ \-/+ + \-/\ +---+ +
+ | \ / + + \ +
+---+ | \/-\/ +/-\+ \ +---+
| 2 | | ( D )------( E ) \ | 5 |
+---+ | \-/ \-/ \ +---+
# | # # \ \ #
# +---+ /-\ # #/-\ /-\ /-\ +---+ #
###| 3 |######( F )- X -( G )###( H )########( H )##| 6 |##
+---+ \-/ \-/ \-/ \-/ +---+
+++ = working path ### = protection path
Figure 16: Use Case R4 - Restoration of paths keeping full diversity
In the example above a failure affecting W (link B-C) and a failure
affecting P (link F-G) occur, but the server network is able to
provide alternate paths for both of them and still provide the same
level of fault resiliency to the client network.
8. Optimization
8.1. Use case O1 -
TBD
9. Security Considerations
TBD
10. IANA Considerations
TBD
11. Contributors
Diego Caviglia
Email: diego.caviglia@ericsson.com
Ceccarelli, et al. Expires January 12, 2014 [Page 23]
Internet-Draft Overlay model use cases July 2013
Francesco Fondelli
Email: francesco.fondelli@ericsson.com
12. Acknowledgements
The authors would like to thank Manuela Scarella and Enrico Dutti for
the comments and review.
13. References to be added
[EDITOR NOTE] : section to be fixed
[LSP-DIV] - http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-01
[TE-REC] - http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-01
[OF-TEMB] - http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function-metric-bound-02
[SRLG-COLL] - http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-srlg-collect-02
[MELG] - http://tools.ietf.org/html/draft-beeram-ccamp-melg-00
[UNI-APP] - http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-uni-app-03
[ENNI] - http://datatracker.ietf.org/doc/draft-beeram-ccamp-gmpls-enni/
[ISIS-TEMET] - http://tools.ietf.org/html/draft-previdi-isis-te-metric-extensions-03
[OSPF-TEMET] - http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-04
[INTERCON-TE] - http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-00
[UNI EXT] - http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-01
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References
Authors' Addresses
Daniele Ceccarelli
Ericsson
Via E. Melen 77
Genova - Erzelli
Italy
Email: daniele.ceccarelli@ericsson.com
Ceccarelli, et al. Expires January 12, 2014 [Page 24]
Internet-Draft Overlay model use cases July 2013
Oscar Gonzalez de Dios
Telefonica I+D
Don Ramon de la Cruz 82-84
Madrid 28045
Spain
Email: ogondio@tid.es
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 P.R.China Bantian, Longgang District
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Xian Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 P.R.China Bantian, Longgang District
Phone: +86-755-28972913
Email: zhang.xian@huawei.com
Ceccarelli, et al. Expires January 12, 2014 [Page 25]