Internet DRAFT - draft-choi-pce-l1vpn-framework
draft-choi-pce-l1vpn-framework
Network Working Group Jun Kyun Choi (BcN ERC)
Internet Draft Dipnarayan Guha (NTU)
Category: Informational
Expires: January 2007 August 2006
Framework of PCEMP based Layer 1 Virtual Private Network
draft-choi-pce-l1vpn-framework-05.txt
Status of this Memo
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Copyright (C) The Internet Society (2006).
Abstract
When path computation is done in the management systems for Layer 1
Virtual Private Networks (L1 VPNs), it would be important that
resource information is synchronized between the management systems
and the Provider Edge /Provider (PE/P). This draft looks at such a
scenario from the viewpoint of the Path Computation Element Metric
Protocol (PCEMP) that acts a generic computation model for path
based metrics in large multi-domain or multi-layer networks. This
draft shows how PCEMP messages might help preserving the path
computational entities in the L1 VPN peer nodes.
This draft proposes to show how a L1 VPN framework may be included
within the scope of Path Computation Element architectures and is
derived primarily from the motivation of per VPN peer service
solutions using PCE techniques. PCEMP metrics defining path quality
measurement criteria, algorithm complexity and scalability criteria
for L1 VPNs is in line with the functional specifications of
Generalized Traffic Engineered LSP path computation techniques
involving Path Computation Element(s) of the PCE WG Charter.
Choi, Guha Informational [Page 1]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
Table of Contents
1 Terminology ................................................. 3
2 Introduction ................................................ 4
3 L1 VPN service models and architecture frameworks ........... 4
3.1 L1 VPN Network Topology ................................. 4
3.2 Current technologies for dynamic L1 provisioning and
deficiencies ................................................ 5
3.3 Per VPN Peer Service Model .............................. 5
3.4 Resource management per VPN ............................. 6
4 Key features of PCEMP ....................................... 6
4.1 Other features of PCEMP for L1 VPN dynamic provisioning . 7
5 Path Computation fundamentals applicable to dynamic L1
provisioning ................................................ 9
5.1 Introduction to PCE nodes and PCEMP peers over the
control network ............................................. 9
5.2 Network structure considerations ........................ 10
5.3 Control structure considerations ........................ 10
5.4 Segment wise partitioning using the PCE nodes ........... 10
5.5 Complete Network Topology for L1 VPN networks: A PCE
perspective ................................................. 11
5.6 Protocol implementation considerations using PCEMP ...... 13
5.6.1 PE-P L1 connection ................................ 13
5.6.2 PE-P-PE L1 connection (teardown invoked from any
PE) ............................................... 14
5.6.3 PE-P-PE L1 connection (teardown invoked from any
P) ................................................ 15
5.6.4 Inter-domain point-to-multipoint considerations ... 15
6 Overview of PCE node requirements for dynamic L1 VPN
provisioning ................................................ 16
6.1 Protocol level hierarchy architecture on the L1
control plane ............................................... 16
6.2 PCEMP peer architecture as seen by the PCEMP protocol ... 17
7 Conclusion .................................................. 18
8 Security Considerations ..................................... 18
9 IANA Considerations ......................................... 18
10 Acknowledgements ............................................ 18
11 Intellectual Property Considerations ........................ 18
12 Normative References ........................................ 19
13 Informational References .................................... 19
14 Authors' Addresses .......................................... 21
15 Full Copyright Statement .................................... 21
Choi, Guha Informational [Page 2]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
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].
The reader is assumed to be familiar with the terminology in
[RFC3031], [RFC3209], [RFC3471], [RFC3473], [GMPLS-ROUTING] and
[PPVPN-TERM].
This memo makes use of the following terms:
1. Virtual link: A provider network TE link provided to customers
in routing information for purposes which include path computation.
A physical link may or may not exist between two end points of a
virtual link [1].
2. Virtual node: A provider network logical node provided to
customers in routing information. A virtual node may represent a
single physical node or multiple physical nodes and links [1].
3. VPN end point: CE's port, connected to a PE device, which is
part of the VPN membership [1].
4. VPN connection (or connection in L1 VPN context): A connection
between a pair of VPN end points. In some scenarios, A VPN
connection may be established between a pair of Cs (customer
devices) [1].
5. Path Computation Element (PCE): an entity that is responsible
for computing/finding inter/intra domain LSPs. This entity can
simultaneously act as client and a server. Several PCEs can be
deployed in a given AS.
6. Path Computation Element node (PCE Node): a network processing
unit comprising of a PCE unit. This can be embedded in a router
or a switch.
7. Domain: Denotes an Autonomous system (AS) within the scope of
this draft.
Choi, Guha Informational [Page 3]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
2. Introduction
This draft addresses L1 VPN frameworks from the PCE perspective with
the motivation of per VPN peer service model architecture
realizations. L1 VPNs provide services over layer 1 networks. This
draft provides a framework by those networks controlled by GMPLS
protocols. In this context, we show how PCEMP [2], set out by the
metric definition and analysis requirements of PCE models set forth
by the PCE WG Charter for an internet routing protocol, may help
realize this motivation of the peer service model. The next sections
of this draft go on to show how PCEMP can be a satisfactory solution
to L1 VPN resource management using path computation techniques.
The purpose of this draft is informational and is in line with the
requirements and architecture work in this field that has been
undertaken and is currently going on within the ITU-T.
3. L1 VPN service models and architecture frameworks
3.1 L1 VPN Network Topology
The L1 network, made of Optical Cross-Connects (OXCs) or Time
Division Multiplex (TDM) capable switches (we address them as L1
nodes), may be seen as consisting of provider edge (PE) devices
that give access from outside of the network, and provider (P)
devices that operate only within the core of the network.
Similarly, outside the layer 1 network is the customer network
consisting of customer (C) devices with access to the layer 1
network made through customer edge (CE) devices [1].
A CE and PE are connected by one or more links. A CE may also be
connected to more than one PE, and a PE may have more than one CE
connected to it [1]. Figure 1 shows such a diagram derived from [1]
+--------------------------------+
| |
| | : +------+
| +------------+ | : | CE |
| | Management | | : |device|
| | system(s) | +------+ : | of |
| +------------+ | |==:=|VPN A|
| | | : +------+
+------+ : | L1 | PE | : +------+
| CE | : | connection |device| : | CE |
|device| : +------+ +------+ | | : |device|
| of |=:==| |==========| |==========| |--:-| of |
|VPN A| : | | | | +------+ : |VPN B|
+------+ : | PE | | P | | : +------+
+------+ : |device| |device| | : +------+
| CE | : | | | | +------+ : | CE |
|device|=:==| |==========| |==========| |--:-|device|
| of | : +------+ +------+ | | : | of |
|VPN B| : | | PE | : |VPN A|
+------+ : | |device| : +------+
: | | | : +------+
: | | |==:=| CE |
: | +------+ : |device|
: | | : | of |
: | | : |VPN B|
: | | : +------+
Customer | | Customer
interface | | interface
+--------------------------------+
|<------ Provider network ------>|
| |
Figure 1: L1 VPN reference model [1]
Choi, Guha Informational [Page 4]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
In L1VPN, L1 connections are provided between CE's physical
interfaces within the same VPN. In Figure 5.1, a connection is
provided between the lefthand CE of VPN A and the upper righthand CE
of VPN A, and another connection is provided between the lefthand CE
of VPN B and lower righthand CE of VPN B (shown as "=" mark) [1].
3.2 Current technologies for dynamic L1 provisioning and deficiencies
Current UNIs (User Network Interfaces) include features to facilitate
requests for end-to-end (i.e. CE-CE) service requests that include
the specification of constraints such as explicit paths, bandwidth
requirements, protection needs, and destinations.
The UNIs, however, do not provide a sufficiently high level of
service to support VPNs without some additions. For example, there is
no way to distinguish between control messages received over a shared
control link (i.e., a control link shared by multiple VPNs) at a UNI,
and these messages must be disambiguated with respect to the L1VPN to
which they apply [1].
Further, there is currently no leakage of routing information across
the PE to CE boundary. While this restriction may be considered
desirable from the perspective of network separation, VPN operation
may benefit from the dynamic exchange of routing information
between CEs that provide access to the VPNs.
In order that L1 VPNs can be supported in a fully functional manner,
these deficiencies and other requirements must be addressed.
The Path Computation technique may be a useful solution to overcoming
these deficiencies in current technologies for dynamic L1
provisioning. We will show how PCEMP and the associated protocol and
PCE unit architecture is beneficial for the support of L1 VPNs.
3.3 Per VPN Peer Service Model
Figure 2 describes the per VPN peer service model.
+--------------------+
| |
+----+ : +----+ +----+ +----+ : +----+
| CE |-------:---| PE |----| P |----| PE |---:-------| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: |<-Provider network->| :
Customer Customer
interface interface
Figure 2: Per VPN peer service model [1]
Choi, Guha Informational [Page 5]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
In this service model, the provider partitions the TE links within
the provider network per VPN, and discloses per VPN TE link
information to corresponding CEs. As such, a CE receives routing
information of PE-CE links, remote CE sites, as well as partitioned
portions of the provider network. This is a good scope of work for
PCE techniques, with the partitioning of PCEDAs (PCE Domain Areas)
as shown later on in this draft. Virtual links may be constructed
between two nodes where direct physical links do not exist, or
virtual nodes may be constructed to represent multiple physical
nodes and links. This is in line with the PCEMP model and a direct
consequence of the protocol architecture.
3.4 Resource management per VPN
In this type of service model, one optional requirement is resource
management for a dedicated Data-Plane (the provider network
partitions link resources per VPN for exclusive use by a particular
VPN), and resource management for sharing the Data-Plane among a
specific set of VPNs (the provider network assigns link resources
to a specific set of VPNs). A simple way to meet this requirement
is to implement resource management functionalities in the management
systems. However, if the PE/P need path computation locally, not
relying on the management systems, then support of resource
management in PE/P (e.g., routing protocol extension) is necessary.
This is especially beneficial in the case of dynamic restoration
(restoration that does not reserve backup resources in advance).
When path computation is done in the management systems, it would
be important that resource information is synchronized between the
management systems and PE/P.
This is a good scope for the PCEMP architecture where resource
management support can take place through the SCMs and Fast
decoding outputs [2].
Currently, there is no solution document for this type of service
model [1]. This draft using PCEMP could be a suitable answer
apart from the suggestions suggested in [GVPN] or the virtual
router approach [VR].
4. Key features of PCEMP
This section summarizes the key features of the PCEMP protocol. PCEMP
is a generic domain routing and path computation protocol that runs
on any PCE unit that is capable of computing a path based on an
ordered graph. PCEMP uses data vector techniques for path computation.
Individual link state advertisements (LSAs) are mapped onto the
computation units directly at TE-LSP setup time. Each PCE unit
maintains this mapping information through the controller unit [3]
and the mapping synchronization of the LSDBs are performed using PCEMP
finite state machines. From this central controller sub-units, each
Choi, Guha Informational [Page 6]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
PCE constructs a routing table by calculating a shortest data vector
tree, the root being the calculating PCE node itself.
4.1 Other features of PCEMP for L1 VPN dynamic provisioning
The other features of the PCEMP protocol that are helpful for dynamic
L1 provisioning are:
1. Central Controller (CC). The central controller acts as the
originator of the network's local information environment. The
controller also acts in the global scenario of inter domain PCEs and
inter layer networks. It serves as the key functional point of the
data vector driven algorithm for all PCE information and link state
synchronizations by co-ordinating LSP advertisements from other PCEs
and LSRs. This is the key element in the L1 VPN peer entities.
2. Soft PCE Controller (SPC). A Soft PCE Controller is an entity
designed primarily for protection and fast route establishment in
conjunction with the Central Controller. The SPC's primary
functionality is to provide a robust and real-time path computation
adjacency without crossover delays for the data driven algorithm
mechanism. Also, this enables the LSP state and path computation
state retention in case of nodal faults and hardware failures.
3. Support for peer adjacency through non-participating interior
nodes. PCEMP treats these nodes opaquely and is able to maintain
the PCE adjacencies over inter-domains and inter-layer networks. The
protocol is generic and can be easily carried over existing routing
mechanisms over non-supporting network clouds. There is no necessity
for any additional configuration updates for PCEs attached to such
networks for initial discovery as the data driven mechanism is flow
based. This is necessary to support peer L1 provisioning over
different domains.
4. PCE domain areas (PCEDA). PCEMP allows the formation of distinct
PCE domain areas in a specific domain for end-to-end peer
participations. This is useful for several reasons. This is in line
with the protocol architecture that provides a granularity of data
protection within an autonomous system and isolation of data to
local branches of the tree. This is also helpful for the design of
the PCE units using soft memory techniques and reduces the
algorithm operation costs. In the per VPN peer service model,
the provider partitions the TE links within the provider network
per VPN, and discloses per VPN TE link information to corresponding
CEs. The partitioning of PCEDAs using PCEMP is a direct driver to
this mechanism.
5. Data driven mapping of external routing information. In PCEMP,
each external route is imported into the PCE domain area in separate
data driven computation strategies. This reduces the amount of
instantaneous re-computation of routing traffic data. It also
Choi, Guha Informational [Page 7]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
enables partial controller database updates when there is a partial
external route change. This helps in setting up the L1 VPN paths
with minimal provisioning turnaround time.
6. Three level functional control hierarchy. PCEMP has a three level
controller hierarchy, intra-PCE-domain, inter-PCE-domain and
external-PCE-domain. This is discussed in the context of the
Centralized Controller [3] and the L1 VPN provisioning blocks in the
PCE nodes.
7. Virtual link mapping. This is done via the real-time configuration
of logical local links based on the data-driven strategy of the
algorithm. The mechanism is thus made topology independent and
generic and can be applied to the Network Topology structure of a
L1 VPN as shown in Figure 1.
8. Soft Computation Memory (SCM). This is a novel feature in terms of
path computation in the CC and SPC. It helps split the tree into a
combination of sparse subtrees for fast computation. SCM can be used
to assign metrics of path computation as well as compute data-driven
flow based mappings in the PCE.
9. Data-driven routing metric. In PCEMP, the computation metrics are
assigned to the outbound router interfaces and the soft memory cycles
in the PCE controller unit. The cost of a path is then the weighted
sum of the path's component interfaces and the soft memory cycles.
The routing and external path metrics can be assigned externally.
We now address some of the Path computation fundamentals applicable
to dynamic L1 provisioning and define the architecture on which the
PCEMP may be applicable.
Choi, Guha Informational [Page 8]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
5. Path Computation fundamentals applicable to dynamic L1 provisioning
__________________Control/Management Network_________
/ \
/ +--+ PCEMP peer +--+ PCEMP peer \
/ | |-------------------| |------------------------\
/ +--+PCE node +--+PCE node ........ \
\ /|| /|| ........ /
\ / | \ / | \ /
\___|_|__\_________________|_|__\______________________/
| | | | | \
/ | \<-------------> / | |<--------------------...>
Control / | \ PCEMP / | \ PCEMP ........ PCEMP
Channel / | \ / | \ ........ peers
_______/____|_____ \___ _____/____|______\_____
\ +--+ | +--+ | \ +--+ | +--+ |
\ | |L1 | | | | \ | | | L1 | | |
\ +--+Node | +--+ / \ +--+ |Node +--+ /
\ \ | / / \ \ | / /
\ \ | / / \ \ | / / ........
\ \ | / / \ \ \ / / ........
\ +--+ / \ +--+ /
\ | | / GMPLS \ | | /
\ +--+ / \ +--+ / Layer 1
\ / \ / Network
\____/ \_____/
Figure 3. PCE-L1 node based L1 VPN framework using PCEMP
Figure 3 shows the layered architecture of a PCE based L1 VPN
framework for per VPN peer service model. The model is
facilitated by the use of GMPLS, which supports a concept of
common control of packet, TDM, wavelength and fiber services, part
of the Layer 1 network, and is a key enabler of this new network
architecture model using PCE techniques.
5.1 Introduction to PCE nodes and PCEMP peers over the control network
This draft addresses the coordination of the IP and optical network
provisioning in the L1 VPN scenario based on a consolidated PCE node
and a truly integrated control plane. This PCE node, which comprises
the path computing unit that supports PCEMP, enables an integrated
network architecture where each network layer can freely exchange
topology and resource information. This allows network performance
to be globally optimized across all layers. In addition, a single
control plane and the PCEMP peers that manage all network layers
simplify network management tasks and facilitate dynamic L1
provisioning.
As far as control and management types for L1 networks are concerned,
they can be classified into three categories: centralized,
distributed and hybrid control/management. Each control and
Choi, Guha Informational [Page 9]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
management type has its' own advantages and disadvantages, but
typical telecommunication networks and automatic switched optical
networks (ASON) defined in ITU-T follows a centralized control/
management architecture in which the control plane is separate from
the data plane. In this draft, for path computation purposes, we
consider the control plane to be separated logically from the data
plane. Separate PCE nodes or control/management networks comprising
a series of PCEMP peers could be connected to each other by through
signaling channels and appropriate PCEMP message exchanges. If the
domains of the control/management networks increase, a hierarchical
control/management structure could be applied. This can be fully
realized in the PCE node through functional blocks defined by the
SCM [2]. There is a channel interface between the PCE node and any
L1 node in the Layer 1 network, and this can be realized using PCEMP.
In this architecture, the PCE node is responsible for path
calculation, recovery and provisioning. Some of the recovery
functions are also assigned to nodes in the Layer 1 network for the
purpose of control and load balancing.
5.2 Network structure considerations
Each PCE node is assumed to have L1 and L2/L3 router capabilities in
the same hardware setup, which results in the support of multiple
traffic types at the same location. The traffic manager in each
L1 node also manages multiple traffic types. Each L1 node can
communicate directly with the corresponding PCE node to report its
status. As mentioned in Section 5.1, this is achieved via PCEMP.
The PCE nodes takes care of L1 nodes within the same PCEDA. They
also have the responsibility of centralizing domain network management
service and integrating the management of the L1 network in their
respective domain. This structure permits scalability as well as
internetworking of different administrative domains.
5.3 Control structure considerations
Network elements within each domain communicate with one another
via a common control plane. We assume a dedicated out-of-band control
channel between two adjacent nodes, and between each L1 node and the
PCE node. The common control plane can be implemented based on GMPLS.
Apart from RSVP and CR-LDP extensions to GMPLS, PCEMP can provide
traffic engineering in this unified network architecture for dynamic
L1 VPN provisioning. Metrics of PCEMP in this regard remains an issue
for future study. Moreover, neighbor discovery and link state update
can employ routing LSA protocols like ISIS and OSPF extensions to
GMPLS.
5.4 Segment wise partitioning using the PCE nodes
As a network becomes large, the size of the sub networks also become
large. Segment wise partitioning into PCEDAs are effected by the PCE
nodes in the integrated network architecture as mentioned in Section
Choi, Guha Informational [Page 10]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
3.1. Additionally, this can support fast recovery and can take care
for partially multiple simultaneous failures using the SPCs in the
PCE nodes and thus effect fast dynamic provisioning with the
minimal crossover time.
The main concept is to partition a large network into several small
networks to configure the path computing information to each small
network. This is one of the major functionalities of the PCE nodes,
which effectively partitions the addressed domain into respective
PCEDAs using the three functional blocks, the Network Processor,
Domain Processor and Node Processor [2]. PCEDAs are chosen according
to network provisioning such as physical layer conditioning, call
demands or QoS demands, which may arise from the user. The following
shows a segment wise PCEDA architecture, with the PCE nodes managing
the different domain areas.
PCEDA 1 PCEDA 2 PCEDA 3
+-----------------+--------------+------------------+
| +--+ | +--+ | +--+ |
| |PCE| | |PCE| | |PCE| |
| //+--+\\ | /+--+\ | //+--+\\ |
| // \\ | / \ | // \\ |
| // \\ | / \ | // \\ |
| +--+ +---+ +---+ +--+ |
| |L1| |L1 | |L1 | |L1| |
| +--+ +---+ +---+ +--+ |
| \ / | \\ // | \ / |
| \ / | \\ // | \ / |
| \ / | \\ // | \ / |
| +--+ | +--+ | +--+ |
| |L1| | |L1| | |L1| |
| +--+ | +--+ | +--+ |
+-----------------+--------------+------------------+
// : Working path/ : backup path
Figure 4. Segment-wise partitioning into PCEDAs for L1 networks
5.5 Complete Network Topology for L1 VPN networks: A PCE perspective
Based on the above discussions, we can redraw Figure 1 showing the
complete network topology for L1 VPN networks from the PCE
perspective. This is shown in Figure 5.
Choi, Guha Informational [Page 11]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
+--------------------------------+
| |
| | : +------+
| +------------+ | : | CE |
| | PCE node | | : |device|
| | PCEMP peer | +------+ : | of |
| +------------+ | |==:=|VPN A|
| | | : +------+
+------+ : | L1 | PE | : +------+
| CE | : | connection |device| : | CE |
|device| : +------+ PCEMP +------+ PCEMP |PCEMP | : |device|
| of |=:==| |==========| |==========|peer |--:-| of |
|VPN A| : | | | | +------+ : |VPN B|
+------+ : | PE | | P | | : +------+
+------+ : |device| |device| | : +------+
| CE | : |PCEMP | PCEMP |PCEMP | PCEMP +------+ : | CE |
|device|=:==|peer |==========|peer |==========| |--:-|device|
| of | : +------+ +------+ | | : | of |
|VPN B| : | | PE | : |VPN A|
+------+ : | |device| : +------+
: | |PCEMP | : +------+
: | |peer |==:=| CE |
: | +------+ : |device|
: | | : | of |
: | | : |VPN B|
: | | : +------+
Customer | | Customer
interface | | interface
+--------------------------------+
|<------ Provider network ------>|
| |
Figure 5: L1 VPN Network Topology from a PCE perspective
Based on this, we discuss about the aspects of PCEMP and the
computing unit requirements for L1 VPN provisioning for a per
VPN peer service model. Readers can refer to [2] for a detailed
description of the PCEMP protocol.
Choi, Guha Informational [Page 12]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
5.6 Protocol implementation considerations using PCEMP
5.6.1 PE-P L1 connection
|----------- (1) ------------>|
| |
|<-----------(2) -------------|
| |
|------------(3) ------------>|
| |
|<-----------(4) -------------|
| |
|------------(5) ------------>|
| |
|<-----------(6) -------------|
PE P
Figure 6: PCEMP message exchanges between L1 VPN peers (PE/P)
For a single PE-P per VPN connection, we can use PCEMP messaging for
implementing the L1 VPN framework using PCE techniques. Here is a
sample sequence of messaging that helps in the L1 VPN PE/P nodes
maintain soft PCEMP status. Details about the protocol messages can
be found in [2].
(1): Send a PCEMP Common Header with the COMPUTE_PATH enabled in the
PCEMode field and the ACK REQUESTED enabled in the PCEFlag field.
The PCEMP message MAY include a PCE SUBOBJECT to inform the
responder (P) about the initiator's (PE)
PCEMP-LOCAL-INITIATOR-ADDRESS. In this way the PE is initialized
with the soft-memory based computation for PCEMP FSMs.
(2): P receives this message and is configured with the soft-memory
based path computation states. (If P does not support this, it
may be needed to be configured administratively). It sends back
an ACK message to the PE with the responder's (P)
PCEMP-LOCAL-RESPONDER-ADDRESS
(3): PE sends a PCEMP Common Header with the ESTABLISH_PATH enabled
in the PCEMode field and the Peer-to-peer mode set in the
PCEStatus field of the Common Header. It also sends a PCEMP
ESTABLISH message with the following parameters:
1. Flag field set to VARIABLE. The MAX_PCE_TIME_FIT is to be
negotiated as discussed in [2]. In case this is not able to
be negotiated, then the PCEMP ERROR message SHOULD be
generated with the ERROR CODE field set to OUT OF TIME, and
the PE node MUST issue a fresh PCEMP ESTABLISH message with
the Flag field set to STATIC.
2. The BANDWIDTH OBJECT is mandatory for the PCEMP Common
Header with the Peer-to-peer mode set in the PCEStatus field.
If this object is absent, a PCEMP ERROR message MUST be
Choi, Guha Informational [Page 13]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
generated with the ERROR CODE field set to PROTOCOL ERROR
along with its' supported bandwidth in the PCEMP NEGOTIATE
OBJECT, following which the initiator requests a fresh
PCEMP ESTABLISH message with the BANDWIDTH OBJECT equal to
the PCEMP NEGOTIATE OBJECT.
(4): P sends a PCEMP RESPOND message with the corresponding PCE
Descriptor ID. This is matched and stored statically for the
lifetime of the path computation between P-PE so that this ID
remains static between them till the path computation is over.
If the PCE Descriptor ID changes value, a PCEMP ERROR message
MUST be generated with the ERROR CODE field set to PROTOCOL
ERROR with its own saved PCE Descriptor ID of the wronged hop
in the PCEMP NEGOTIATE OBJECT. It MUST also set the Protection
mode in the PCEStatus field of the corresponding outgoing
PCEMP Common Header.
(5): PE issues a PCEMP TEARDOWN message with the RequestType field
set to CHANGE IN COMPUTATION STYLE for PE to remain PCEMP
enabled and the path computation state active. The L1 VPN
peers thus maintain their path computation enable for the
architecture framework as discussed earlier in this draft.
(6): P sends a PCEMP Common Header with the COMPUTE_PATH enabled in
the PCEMode field. The PCEMP message MAY include a PCE
SUBOBJECT to inform the responder (PE) about the initiator's
(P) PCEMP-LOCAL-INITIATOR-ADDRESS.
5.6.2 PE-P-PE L1 connection (teardown invoked from any PE)
|----------- (1) ------------>| |
| |-----------(1A) ----------->|
|<-----------(2) -------------| |
| |<----------(2A) ------------|
|------------(3) ------------>| |
| |-----------(3A) ----------->|
|<-----------(4) -------------| |
| |<----------(4A) ------------|
|------------(5) ------------>| |
| | |
|<-----------(6) -------------| |
PE1 P PE2
Figure 7: PCEMP message exchanges between L1 VPN peers (PE-P-PE)
Teardown invoke from any PE
This follows from Section 5.6.1, with (1A), (2A), (3A), (4A)
being identical to (1), (2), (3) and (4). (5) and (6) are also
identical as in the previous section. The only point of study is
Choi, Guha Informational [Page 14]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
the path computation state of PE2. The Teardown message may be
propagated to PE2, like the Establish and the Respond messages,
in which case it is trivial to the PE-P case. In Figure 7, PE2
still remains in the active state, i.e. it is capable of generating
PCEMP messages on its own. The Path Computation state of PE2 is
local to it, and is completely independent of what happens at PE1.
This is a very big advantage in realizing PCE based L1 per VPNs.
PE2 can alternately serve the next PCEDA using the path computation
state information of PE1 learnt through processes (1), (2), (3) and
(4). This means that there is always a guaranteed virtual topology
link from PE1 to the other PEs, which means that L1 VPN
provisioning is also guaranteed.
5.6.3. PE-P-PE L1 connection (teardown invoked from any P)
|----------- (1) ------------>| |
| |-----------(1A) ----------->|
|<-----------(2) -------------| |
| |<----------(2A) ------------|
|------------(3) ------------>| |
| |-----------(3A) ----------->|
|<-----------(4) -------------| |
| |<----------(4A) ------------|
|<------------(5) ------------| |
| |-----------(5) ------------>|
|-----------(6) ------------->| |
| |<----------(6)--------------|
PE1 P PE2
Figure 8: PCEMP message exchanges between L1 VPN peers (PE-P-PE)
Teardown invoke from P
In this case, path computation states are preserved among all the
participating entities. P here would ideally act as the PCE node
initiator for multiple PCEDAs (multi-layer networks in particular)
and multiple TE-LSPs shared by different paths between different
L1 VPN peers. The advantage of this is superior path protection
and bandwidth utilization.
5.6.4 Inter-domain point-to-multipoint considerations
The protocol implementations are followed as in the previous section,
except for a few modifications.
Before Step (3) as in 5.6.1, the PE node needs to send a PCEMP
Common Header with the COMPUTE_LSP_TYPE set in the PCEMode and the
Peer-to-peer mode set to either 0, 1 or 2 in the PCEStatus, as in [2].
This precedes Step (3) in 5.6.1. The PE node MUST also send a
BANDWIDTH OBJECT in the corresponding PCEMP ESTABLISH message, the
absence of which signifies a protocol error. The participating PCE
peers thus get information that the path computation session is a
point-to-multipoint one. If the BANDWIDTH OBJECT is not supported,
the corresponding peer MAY generate a PCEMP ERROR message with a
PCEMP NEGOTIATE OBJECT and the BANDWIDTH OBJECT identical to each
Choi, Guha Informational [Page 15]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
other. The paths may even be aggregated for multipoint-to-multipoint
TE LSP path computation in inter-domains.
In this mode of operation, Step (6) in 5.6.1 is replaced with the P
(or Pn, in the more general case) sending a PCEMP Common Header
with the COMPUTE_LSP_TYPE enabled in the PCEMode field and the
Peer-to-peer mode set along with the BANDWIDTH OBJECT. The BANDWIDTH
OBJECT should be retained across inter-domain LSPs.
6. Overview of PCE node requirements for dynamic L1 VPN provisioning
The architecture of the PCEMP protocol using soft memory concepts
in the context of path computing block requirements is the key
factor for dynamic provisioning in Layer 1 VPNs. The network graph
is constructed and analyzed real time inside the core of the PCE
node with the aid of soft decision algebraic polynomial algorithms.
The system is robust and guarantees efficient path computation for
large scale data vectors and handle efficient segmentation of
inter-domains and inter-layer networks into PCEDAs during path
computation, thus effectively realizing the per VPN peer model.
It also reduces computational complexity of data intensive
processing.
The requirements of a PCE node that helps to ease computationally
intensive data processing for integrated provisioning in
inter-domain and inter-layer networks have been discussed in
Section 5. The PCEMP along with the CC and SPC as part of the PCE
node enables an integrated network architecture where each network
layer can freely exchange topology and resource information. This
allows network performance to be globally optimized across all
layers.
6.1 Protocol level hierarchy architecture on the L1 control plane
In an integrated control plane, three levels of functional control
hierarchy are mapped into one PCE node in the core of the Network
Processing engine and implemented as a single unit. PCEMP thus has a
three level control hierarchy, intra-PCE-domain, inter-PCE-domain
and external-PCE-domain. This is used to manage the PCEMP peers
on the integrated network architecture as shown in Figure 3.
The functional blocks involved in the PCE node are: the network
processor (the network management system with extended
functionalities), the domain processor (the network element management
system with extended functionalities), and the node processor. These
are invoked by the PCEMP state machines and comprise the fundamental
protocol level hierarchies on the control plane. In the first level,
the network processor acts as an interface between users and all
sub-network domains. Its' main functionality is to oversee the
provisioning of new connections across multiple sub-networks and to
maintain the network-wide topological view by reducing the
Choi, Guha Informational [Page 16]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
computational domains to PCEDAs. The domain processor supervises tasks
within a sub-network domain, such as service provisioning and network
status monitoring. It handles requests for connection setup and
teardown, and computes explicit paths that meet the SLA of each
request. The network monitor observes the overall network health and
detects failure and repair events. The databases maintained by the
domain processor include the domain topology, the domain link state
database gathered via the LSA protocol within its domain, and the
domain connection database which keeps track of all established
connections in the domain. The node processor manages specific
functionalities that can be done in a distributed manner at each node,
such as overload handling, failure recovery, and status monitoring.
It also detects sudden link overloads, conducts a countermeasure and
provides rapid protection and restoration capability in times of
failure. The databases maintained by the node processor are the local
link state and the local connection databases. The local link state
is obtained automatically via the neighbor discovery protocol, while
the list of local connections is obtained from all connections that
traverse the node. These are implemented using soft memory concepts
and synchronized using PCEMP.
For the purpose of establishing a guaranteed a disjoint backup path
and fast restoration techniques in the participating PCEDAs, it is
essential that the large scale data processing in the CC and SPC have
minimum overhead and processing delay. The CC manages the entire
domain network, as discussed in [2]. In this architecture, backup
paths can be easily established end-to-end using the logical
configuration in the SPCs using PCEMP. Based on the data driven
routing metric table, which is configured at each PCE node by the CC,
one can make a robust real-time path between a source node and a
destination node and many intermediate nodes between the two. This
is done using soft decision PCEMP algorithms.
All this is used for dynamic L1 VPN provisioning.
6.2 PCEMP peer architecture as seen by the PCEMP protocol
These are the PCEMP peer architectures as seen by the PCEMP protocol
state machines during path computation. From Figure 5, we see that
the participating nodes in the integrated network for L1 VPN topology
become corresponding PCEMP peers.
1. A matrix and parallel vector arithmetic unit that provides
parallel data processing capabilities on the commonly used matrix and
vector mathematical data types. Performance of this unit is
independent of the size of the data vector under computation. This is
implemented in the CC and SPC.
2. The processing core that provides the ease of programming and
flexibility to address changing algorithms and standards. There
exists a one-to-one map from the transform computed by the core to
the high-level code generated by the PCE application. This is
implemented using soft memory techniques in the CC, SPC and SCM.
Choi, Guha Informational [Page 17]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
3. A high-speed I/O system that allows complex, adaptive algorithms
to be partitioned cost-effectively across multiple sub PCE unit
blocks by providing dual ports. These ports are logically
indistinguishable across the ordered pair of a data vector and the
corresponding transform that is executed.
These units are images of the PCE computing unit that are mapped onto
the PCEMP state machines and thus make all the participating entities
PCEMP supportive.
7. Conclusion
We have shown that a path computation technique based architecture
might be a good solution towards dynamic L1 provisioning in per
VPN peer based service models. There is perfect synchronization
of resource information between PCEMP peers using the PCEMP DS [2].
This draft addresses L1 VPN frameworks from the PCE perspective which
is a relatively new way of describing such an architecture. In this
context, PCEMP helps to realize this motivation of the peer service
model. Resource management level granularity is mapped onto using
PCEMP DS [2].
Traffic Engineering and protocol performance under stress remain
topics of future study.
8. Security Considerations
The impact of the use of the PCEMP architecture is relatively much
secure as the PCEDA are computed and distributed internal to the PCE
unit. An increase in inter-domain information flows and the facilitation
of inter-domain path establishment through PCEMP does not increase the
existing vulnerability to security attacks. It should be remembered that
PCEMP works by an invoked logic scheme local to each participating PCE
unit, and the protocol scheme is brought into play only when there is a
significant change in the data profile within the time of goodness of fit.
However, it is expected that the PCE solutions will address security
issues mentioned in [Ash] in details using authentication and
security techniques.
9. IANA Considerations
This document makes no requests for IANA action.
10. Acknowledgements
This work was supported by BcN ITRC, Ministry of Information and
Communications (MIC), Republic of Korea
11. Intellectual Property Considerations
Choi, Guha Informational [Page 18]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has made
any independent effort to identify any such rights. Information on
the procedures with respect to rights in RFC documents can be found
in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
13. Informational References
[1] Takeda, T., Editor "Framework and Requirements for Layer 1
Virtual Private Networks", draft-ietf-l1vpn-framework-03.txt, April
2006.
[2] Choi, J.K., and Guha, D., "Path Computation Element Metric
Protocol (PCEMP)", draft-choi-pce-metric-protocol-05.txt, August
2006 (work in progress)
[3] Choi, J.K., et al., "Fast End-to-End Restoration Mechanism with
SRLG using Centralized Control", draft-choi-pce-e2e-centralized-
-restoration-srlg-06.txt, August 2006 (work in progress)
[4] Takeda, T., "Applicability analysis of GMPLS protocols to Layer
1 Virtual Private Networks", draft-ietf-l1vpn-applicability-01.txt,
March 2006
[Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic
requirements and architecture elements, ITU-T Recommendation,
September 2003.
Choi, Guha Informational [Page 19]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
[Y.1313] Y.1313 - Layer 1 Virtual Private Network service and network
architectures, ITU-T draft Recommendation.
[Y.l1vpnsdr] ITU-T SG 13 work in progress
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
label switching Architecture", RFC 3031, January 2001.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus,
"Requirements for Traffic Engineering over MPLS", RFC 2702, September
1999.
[RFC3209] Awduche, D., et. al., "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic Engineering",
draft-ietf-tewg- interarea-mpls-te-req-00.txt, March 2004 (work in
progress).
[INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-06.txt,
January 2004 (work in progress).
[MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture for
Multi-Region Networks,"draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt,
February 2004 (work in progress).
Le Roux, J.L., Ed., "Requirements for Path Computation Element (PCE)
Discovery", draft-ietf-pce-discovery-reqs-05.txt, June 2006
Ash, J., and Le Roux, J.L., Ed., "PCE Communication Protocol Generic
Requirements", draft-ietf-pce-comm-protocol-gen-reqs-07.txt, June
2006
[GMPLS-UNI] Swallow, G., et al., "GMPLS UNI: RSVP Support for the
Overlay Model", draft-ietf-ccamp-gmpls-overlay, work in progress.
[GMPLS-ROUTING] Kompella, K., and Rekhter, Y. (editors), "Routing
Extensions in Support of Generalized MPLS",
draft-ietf-ccamp-gmpls-routing, work in progress.
[L2VPN-FRAME] Andersson, L., and Rosen, E. (editors), "Framework for
Layer 2 Virtual Private Networks (L2VPNs)",
draft-ietf-l2vpn-l2-framework, work in progress.
[L3VPN-FRAME] Callon, R., and Suzuki, M. (editors), "A Framework for
Layer 3 Provider Provisioned Virtual Private Networks",
draft-ietf-l3vpn-framework, work in progress.
Choi, Guha Informational [Page 20]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
[PPVPN-TERM] Andersson, L., and Madsen, T., "PPVPN terminology",
draft-ietf-l3vpn-ppvpn-terminology, work in progress.
[GVPN] Ould-Brahim, H., and Rekhter, Y. (editors), "GVPN Services:
Generalized VPN Services using BGP and GMPLS Toolkit",
draft-ouldbrahim-ppvpn-gvpn-bgpgmpls, work in progress.
[VR] Knight, P., Editor, "Network based IP VPN Architecture using
Virtual Routers", draft-ietf-l3vpn-vpn-vr, work in progress.
14. Authors' Addresses
Jun Kyun Choi
BcN Engineering Research Center
103-6 Munji-Dong, Yuseong-gu, Daejeon, 305-732, Republic of Korea
Phone: +82-42-866-6122
Email: jkchoi@icu.ac.kr
Dipnarayan Guha
Nanyang Technological University, Singapore
Email: dg236@cornell.edu
15. Full Copyright Statement
Copyright (C) The Internet Society (2006). All Rights Reserved.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and translations of it MAY be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation MAY be prepared, copied, published
and distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself MAY not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process MUST be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Choi, Guha Informational [Page 21]
Internet Draft draft-choi-pce-l1vpn-framework-05.txt August 2006
