Overlay Network - Path Computation Approaches
draft-bardalai-ccamp-overlay-path-comp-01
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Snigdho Bardalai , Khuzema Pithewan , Rajan Rao | ||
| Last updated | 2013-07-30 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| 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-bardalai-ccamp-overlay-path-comp-01
INTERNET-DRAFT Snigdho Bardalai
Intended Status: Informational Khuzema Pithewan
Expires: January 31, 2014 Rajan Rao
Infinera Corp.
July 30, 2013
Overlay Network - Path Computation Approaches
draft-bardalai-ccamp-overlay-path-comp-01
Abstract
This document discusses various path computations approaches which
are applicable to overlay networks [framework doc ref]. It discusses
how the customer edge nodes uses the information advertised by the
provider network to compute a path between two customer edge nodes or
how it can request the provider network to compute a path and setup
an end-2-end LSP.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bardalai et.al Expires January 31, 2014 [Page 1]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
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
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. Path Computation Use-cases . . . . . . . . . . . . . . . . . . 3
3. Path Computation Approaches . . . . . . . . . . . . . . . . . . 4
3.1 Virtual Topology Approach . . . . . . . . . . . . . . . . . 5
3.2 PCE Approach . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Hybrid Approach . . . . . . . . . . . . . . . . . . . . . . 11
4. CE-PE / PE-PE Interface . . . . . . . . . . . . . . . . . . . . 11
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 11
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1 Normative References . . . . . . . . . . . . . . . . . . . 12
7.2 Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Bardalai et.al Expires January 31, 2014 [Page 2]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
1 Introduction
This document attempts to describe possible ways to advertise
information required for customer network CE nodes to compute a path
for LSPs between two points in two customer network islands connected
by a provider network, so as to adhere a set of constraints in
provider network without knowledge of the detailed provider network
topology. These constraints could be, but not limited to, diversity,
latency, jitter, skew etc. Connectivity between customer network
islands is presumed to be an "overlay" over provider network.
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 RFC 2119 [RFC2119].
2. Path Computation Use-cases
In case of overlay networks it is required to compute a path between
the customer edge nodes for the overlay FA-LSP as shown in the
figure.
|<========= Overlay FA-LSP ============>|
| |
V V
+---+ __ +---+ _ _ +---+ __ +---+
| |/ \| | +---+ _/ \_ +---+ _/ \_ +---+ | |/ \| |
|C1 | |CE1|---| |/ \| |/ \| |---|CE2| |C2 |
| |\__/| | | | | | | | | |\__/| |
+---+ +---+ | | | | | | +---+ +---+
|PE1| |P1 | |PE2|
+---+ __ +---+ | | | | | | +---+ __ +---+
| |/ \| | | | | | | | | |/ \| |
|C3 | |CE3|---| |\_ _/| |\_ _/| |---|CE4| |C4 |
| |\__/| | +---+ \_/ +---+ \_/ +---+ | |\__/| |
+---+ +---+ +---+ +---+
Figure. 1
The typical path computation use-cases are the following:
1. Point-to-point overlay path.
2. Multiple point-to-point diverse overlay paths sharing common LSP
head and tail ends.
3. Multiple point-to-point diverse overlay paths that do not share
common LSP head and tail ends.
4. Point-to-multipoint overlay paths.
Bardalai et.al Expires January 31, 2014 [Page 3]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
5. Overlay paths over multi-domain (i.e. Multi-area or multi-AS)
provider networks.
The typical TE constraints are:
1. Bandwidth or resource (this is technology specific).
2. Include or exclude nodes/links/SRLG or paths identified by
path-keys.
3. Latency, jitter, max-hop requirements.
4. Optimization options - minimize cost, minimize latency etc.
3. Path Computation Approaches
There are three path computation approaches
1. Virtual-topology approach
2. PCE approach
3. Hybrid approach - combined virtual topology and PCE approach
Bardalai et.al Expires January 31, 2014 [Page 4]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
3.1 Virtual Topology Approach
This path computation approach uses a virtual topology that is
advertised by the provider network by the customer edge nodes.
Customer Network Customer Network
Island 1 Island 2
__ __
/ \ Virtual Links / \
C1 < > CE1-----------PE1======== =========PE3------ CE3 < >C5
\C3/ ++++ \/ ++++++ \C4/
/ \ + /\ + / \
C2 < > CE2-----+---- PE2======== =========PE4-+-----CE4 < >C6
\__/ +++ + + + \__/
----------------- +--+----------------------------+----+-------
+ + ____ ____ + +
+ + / \ / \ + +
+ ++ PE1 < >P1< >PE3++ +
+ \_P3_/ \_P4_/ +
Provider + / \ / \ +
Network ++++++ PE2< >P2< >PE4+++++++
\____/ \____/
Figure. 2
In Figure 2, Provider Network has 4 interconnected rings supports
full node diversity to connect any 2 Provider Edge Nodes.
PE1, PE2, PE3, PE4 are provider edge nodes.
P1, P2, P3, P4 are internal provider Network nodes, that must not be
known to the customer network.
Customer Network has two islands connected by provider network.
C1, C2, C3, C4, C5, C6 are internal customer network nodes.
CE1, CE2, CE3, CE4 are customer network edge nodes connected to
provider network edge nodes PE1, PE2, PE3, PE4.
Virtual Link Set : Virtual Link set is defined as set of one or more
virtual links between any two provider edge nodes. The virtual links
in the virtual link set, when realized may take different paths
within provider domain, having different SRLGs and other TE metrics.
Above example topology has following Virtual Link Sets
a/ [PE1, PE2]
b/ [PE1, PE3]
c/ [PE1, PE4]
d/ [PE2, PE3]
Bardalai et.al Expires January 31, 2014 [Page 5]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
e/ [PE2, PE4]
f/ [PE3, PE4]
The PEs in provider network do full peering with its attached CEs for
virtual topology. So provider network virtual Links along with its
SRLG IDs and other TE metrics are advertised into customer network.
Customer network internal Nodes C1..C6 can see provider network
virtual TE Links and can compute paths between two points in customer
network islands across provider network satisfying required diversity
and TE metrics.
3.2 PCE Approach
An alternative approach for a CE node to obtain a path to another
remote CE node would be by making a request to a provider network
PCE. This approach requires either provider network PE nodes to
advertise the PCE's IP address to CE nodes or CE Nodes should be
configured with Provider Network PCE IP address. CE nodes needs to
advertise the TE link-state of the CE-PE interface. This allows the
PCE to build the overlay network topology link-state data-base.
|<----------------- Client Layer LSP -------------------->|
| |
| |<========= Overlay FA-LSP ============>| |
| | | |
| | |<- Server Layer LSP -->| | |
V V x-NNI| | V V
+---+ __ +---+ | V _ _ V +---+ __ +---+
| |/ \| | V +---+ _/ \_ +---+ _/ \_ +---+ | |/ \| |
|C1 | |CE1|---| |/ \| |/ \| |---|CE2| |C2 |
| |\__/| | | | | | | | | |\__/| |
+---+ +---+ | | | | | | +---+ +---+
|PE1| |P1 | |PE2|
+---+ __ +---+ | | | | | | +---+ __ +---+
| |/ \| | | | | | | | | |/ \| |
|C3 | |CE3|---| |\_ _/| |\_ _/| |---|CE4| |C4 |
| |\__/| | +---+ \_/ +---+ \_/ +---+ | |\__/| |
+---+ +---+ +---+ +---+
Figure. 3
In Figure. 3 above, the example depicted shows the provider network
with a single IGP area and the provider network PCE has visibility to
the detailed topology and TE information representing the server
layer forwarding plane plus the CE-PE interface link-states that have
been learned from the CE nodes. The server layer topology in addition
to the CE-PE interface link-states constitutes the overlay network
Bardalai et.al Expires January 31, 2014 [Page 6]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
topology.
|<----------------- Client Layer LSP -------------------->|
| |
| |<========= Overlay FA-LSP ============>| |
| | | |
| | Server Layer | |
| | |<-- LSP -->| | |
V V x-NNI | | V V
+---+ __ +---+ | _ V _ V +---+ __ +---+
| |/ \| | V +---+ _/ \_ +---+ _/ \_ +---+ | |/ \| |
|C1 | |CE1|---| |/ \| |/ \| |---|CE2| |C2 |
| |\__/| | | | | | | | | |\__/| |
+---+ +---+ | | | | | | +---+ +---+
|PE1| |P1 | |PE2|
+---+ __ +---+ | | | | | | +---+ __ +---+
| |/ \| | | | | | | | | |/ \| |
|C3 | |CE3|---| |\_ _/| |\_ _/| |---|CE4| |C4 |
| |\__/| | +---+ \_/ +---+ \_/ +---+ | |\__/| |
+---+ +---+ +---+ +---+
Figure. 4
Figure. 4 above shows the case in which the provider network is a
multi-layer network and the server layer boundary does not coincide
with the provider network boundary. Again, the provider network PCE
can have visibility to a single IGP area as described for MLN or
alternatively there could be multiple IGP instances as described in
[RFC6107], one instance for the overlay network and another instance
for the server layer.
Bardalai et.al Expires January 31, 2014 [Page 7]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
|<----------------------- Client Layer LSP -------------------->|
| |
| |<============== Overlay FA-LSP ===============>| |
| | | |
| | |<------ Server Layer LSP ----->| | |
V V x-NNI| | V V
+---+ _ +---+ | V _ _ V +---+ _ +---+
| |/ \| | V +---+ _/ \_ +---+ +---+ _/ \_ +---+ | |/ \| |
|C1 | |CE1|---| |/ \| | | |/ \| |---|CE2| |C2 |
| |\_/| | |PE1| D-1 |PE2|---| | | | | |\_/| |
+---+ +---+ /| |\_ _/| | | | | | +---+ +---+
| +---+ \_/ +---+ | | | |
| _ | |PE5| D-3 |PE6|
| +---+ _/ \_ +---+ | | | |
+---+ _ +---+ | | |/ \| | | | | | +---+ _ +---+
| |/ \| |/ |PE3| D-2 |PE4|---| | | | | |/ \| |
|C3 | |CE3|---| |\_ _/| | ^ | |\_ _/| |---|CE4| |C4 |
| |\_/| | +---+ \_/ +---+ | +---+ \_/ +---+ | |\_/| |
+---+ +---+ | +---+ +---+
x-NNI
Figure. 4
Figure. 4 above shows a multi-area or multi-AS provider network
(generalized as a multi-domain provider network in this document).
For multi-domain networks a hierarchical PCE could be deployed and
the IP address of the hierarchical PCE is advertised to the CE nodes.
The hierarchical PCE could maintain a multi-domain virtual topology
instead of detailed topology of each domain.
In all three cases the head-end CE node is assumed to be aware of the
address in the remote CE node for which the path is to be computed.
The exact manner by which this knowledge becomes available is beyond
the scope of this document. The head-end CE node then makes a request
to the provider network PCE with the remote address and the required
set of TE constraints that need to be satisfied by the computed
path.
In each case of the provider networks PCE uses the overlay network
topology to compute the path. In case of the provider network example
shown in Figure. 4 the hierarchical PCE computes the domain-level or
inter-domain path first and then computes the intra-domain paths. The
exact mechanism could be using the BRPC procedure in order to compute
optimal intra-domain paths.
Once the computation is complete the PCE responds back with the path.
The path generated by the PCE is expected to contain both real and
virtual links and nodes. In case there is a need to maintain
Bardalai et.al Expires January 31, 2014 [Page 8]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
confidentiality with respect to the details of the provider network
topology from the customer network then the response can include a
path-key. In case there is a need to compute diverse paths one of two
approaches could be followed - simultaneous computation approach in
which case the response will have multiple paths or path-keys or the
request could include the exclude hops or exclude path-key.
In the example below the procedure of computing a set of diverse
paths using the PCE approach is explained.
Bardalai et.al Expires January 31, 2014 [Page 9]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
|<------------------ Client Layer LSP -------------------->|
| |
| |<=========== Overlay FA-LSP ===========>| |
| | | |
| | Server | |
| | RSVP-TE|<-----Layer LSP-------->| | |
V V PCEP | | V V
+---+ __ +---+ | V _ _ V +---+ __ +---+
| |/ \| | V +---+ _/ \_ +---+ _/ \_ +---+ | |/ \| |
|C1 | |CE1|---| |/ \| |/ \| |---|CE2| |C2 |
| |\__/| | |PE1| | | |PE2| | |\__/| |
+---+ +---+ +---+ | | +---+ +---+ +---+
| |P1 | |
+---+ __ +---+ +---+ | | +---+ +---+ __ +---+
| |/ \| | | | | | | | | |/ \| |
|C3 | |CE3|---|PE3|\_ _/| |\_ _/|PE4|---|CE4| |C4 |
| |\__/| | +---+ \_/ +---+ \_/ +---+ | |\__/| |
+---+ +---+ +---+ +---+
Figure. 5
Step-1: CE1 requests computation of diverse paths between PE1-PE2 and
PE3-PE4.
Step-2: PE1 responds with 2 sets of EROs or 2 path-keys.
Step-3: CE1 initiates signaling of LSP PE1-PE2 with ERO or path-key.
Step-4: ERO or path-key is transferred to CE3.
Step-5: CE3 initiates signaling of LSP PE3-PE4 with ERO or path-key.
This approach uses a single computation for a pair of diverse paths.
An alternative approach is by computing diverse paths separately as
follows:
Step-1: CE1 requests computation of a path between PE1-PE2.
Step-2: PE1 responds with a set of EROs or a path-key.
Step-3: CE1 initiates signaling of LSP PE1-PE2 with ERO or path-key.
Step-4: PE1-PE2 path ERO or path-key is transferred to CE3.
Step-5: CE3 request computation of a path between PE3-PE4 with XRO(=
PE1-PE2 ERO or path-key).
Bardalai et.al Expires January 31, 2014 [Page 10]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
Step-6: PE3 responds with a set of EROs or path-key.
Step-7: CE3 initiates signaling of LSP PE3-PE4 with ERO or path-key.
3.3 Hybrid Approach
In the absence of a hierarchical PCE for a multi-domain provider
network, it is possible a CE node learns of multiple PCE IP addresses
from multiple PE nodes. This is possible in case each PE node lies in
separate areas or ASs and with PCEs deployed per-area or per-AS. In
such a situation it will be necessary for the CE node to pick one of
the PCEs to send the path computation request. One way to select the
appropriate PCE would be to advertise a virtual-topology associated
with each PCE IP address to provide sufficient information for the CE
node to determine whether a path to the remote CE address can be
computed by the specific PCE.
In Figure. 4 above, CE3 has a dual-homed connectivity with the multi-
domain provider network (i.e. CE3 to D-1 and D-2 via PE1 and PE3
respectively). In the absence of a hierarchical PCE, PE1 can
advertise a virtual topology with connectivity to a set of CE nodes.
Similarly PE3 advertises a virtual topology with connectivity to
another set of CE nodes. This can happen in cases when there is no
available bandwidth to a specific CE node via a specific domain. CE3
can determine using the virtual topologies which PCE should it send
the path computation request.
4. CE-PE / PE-PE Interface
The CE-PE or PE-PE interface requires a routing interface in order to
be able to exchange topology information and a path-computation
interface in order to be able to send path computation requests and
responses. For signaling the overlay LSP a signaling interface is
requried as well.
5 Security Considerations
TBD
6 IANA Considerations
TBD
7 References
Bardalai et.al Expires January 31, 2014 [Page 11]
INTERNET DRAFT draft-bardalai-ccamp-overlay-path-comp-01 July 30, 2013
7.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1 1996.
7.2 Informative References
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009.
[RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1
2009.
Authors' Addresses
Snigdho Bardalai
sbardalai@infinera.com
Rajan Rao
rrao@infinera.com
Khuzema Pithewan
kpithewan@infinera.com
Bardalai et.al Expires January 31, 2014 [Page 12]