One document matched: draft-oki-pce-gmpls-req-00.txt
Network Working Group Eiji Oki (NTT)
Internet Draft Takashi Kurimoto (NTT)
Expiration Date: January 2005 Ichiro Inoue (NTT)
Kohei Shiomoto (NTT)
July 2004
Requirements for Path Computation Element
in GMPLS and IP/MPLS Networks
draft-oki-pce-gmpls-req-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 a "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 Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Path Computation Element (PCE) provides functions of traffic engineering
in Generalized Multi-Protocol Label Switching (GMPLS) and IP/MPLS net-
works. In IP/MPLS networks, PCE provides MPLS LSP routes with con-
straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal
virtual network topology reconfiguration control, and jugdes on whether
a new lower-region LSP should be established when a higher-region LSP is
Oki et al. [Page 1]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
requested. PCE also handles interworking between GMPLS and IP/MPLS net-
works, both of which will coexist at some point during the migration
process.
Conventions used in this document
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.
1. Introduction
Path Computation Element (PCE) provides functions of traffic engineering
in Generalized Multi-Protocol Label Switching (GMPLS) and IP/MPLS net-
works. In IP/MPLS networks, PCE provides MPLS LSP routes with con-
straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal
virtual network topology reconfiguration control, and judges on whether
a new lower-region LSP should be established when a higher-region LSP is
requested. PCE also handles interworking between GMPLS and IP/MPLS net-
works, both of which will coexist at some point during the migration
process [OKI-INTERWORK].
GMPLS extends MPLS to support various switching technologies [GMPLS-
ARC]. GMPLS enables us to control a packet switching network, layer 2
switching networks such as asynchronous transfer mode (ATM) and Ether-
net, TDM networks such as synchronous digital hierarchy/synchronous
optical network (SDH/SONET), lambda and fiber networks all at once.
A GMPLS-based multi-region network architecture is addressed in [MRN].
Multi-region traffic engineering in GMPLS networks increase network
resource efficiency, because all the network resources are taken into
account at the same time. However, in GMPLS multi-region network envi-
ronments, traffic engineering becomes more complicated, compared with
that in single-region network environments.
Multi-region traffic engineering includes LSPs route calculation, opti-
mal virtual network topology calculation, and judgement on whether a new
lower-region LSP should be established when a higher-region LSP is
requested. Multi-region traffic engineering also includes control of
virtual network topology reconfiguration, which is triggered by traffic
demand change, by topology change, and by network failure. Single-
region traffic engineering is a subset of multi-region traffic engineer-
ing.
For example, let us consider hierarchical label switched paths (LSPs)
[LSP-HIERARCHY], where a higher-region LSP uses a lower-region LSP as a
Oki et al. [Page 2]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
TE-link. When the higher-region LSP is setup, it is necessary to judge
whether new lower-region LSPs should be established for forwarding adja-
cency LSPs (FA-LSPs), or existing lower-region LSPs should be used for
FA-LSPs. Judgement such as whether new LSPs should be established or
existing LSPs should be used depends on the network providers' traffic-
engineering policy.
This draft describes requirements for Path Computation Element (PCE) in
GMPLS and IP/MPLS networks. Section 2 describes an issue on functional,
or logical, separation between PCE and GMPLS node. Section 3 presents
several traffic engineering scenarios, where PCE is involved. Section 4
describes PCE placement scenarios. Section 5 describes PCE functional
scenarios. Section 6 describes requirements of PCE. Section 7 describes
nodal requirements related to PCE.
2. Functional separation between PCE and GMPLS node
2.1. GMPLS node
A GMPLS node handles GMPLS protocols. When a GMPLS node is a border node
between GMPLS and IP/MPLS networks, the GMPLS node handles both GMPLS
and IP/MPLS protocols.
2.2. Network providers' perspective
Traffic-engineering policies are different among network providers. For
example, when the higher-region LSP is setup, it is necessary judged
whether new lower-region LSPs should be established, or existing lower-
region LSPs should be used. The judgement, which is performed by PCE,
depends on network providers' policy. PCE performance affects the rev-
enue of network providers. Network providers want to have their own PCE,
because they want to choose appropriate algorithms, which depend on
their policies.
2.3. Venders' perspective
It is not desirable to implement PCE that considers all the requirements
from network providers. A complicated PCE may also cause the node to
degrade its processing capability.
Oki et al. [Page 3]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
2.4. PCE implementation
Two approaches for PCE implementation are considered. One is that PCE is
implemented as a part of a GMPLS node. PCE is functionally separated
from a GMPLS node, from network providers' point of view. The other is
that PCE is separately functionally implemented in a GMPLS node.
From the above considerations in Sections 2.1 and 2.2, it is desirable
to functionally separate PCE from a GMPLS node so that network providers
choose their own PCE.
3. Traffic engineering scenarios
This section describes key topics of traffic engineering in GMPLS and
IP/MPLS networks. Multi-region traffic engineering are mainly described.
3.1. Virtual network topology optimization
Two-region GMPLS networks are considered. Discussion on more than two
regions can be easily extended in a similar way. Assume that the higher-
region network is an IP-packet region network, while the lower-region is
an optical network based on TDM or Lambda switching network. The band-
width granularity of the lower region is coarse. For example, the band-
width is equal to 2.5Gbit/s or 10Gbit/s. On the other hand, the granu-
larity of the higher region is flexible and well engineered.
Consider the case in which source and destination IP routers request
packet (higher-region) LSPs with specified bandwidths. Higher-region
LSPs are routed on the optical network that consists of optical (lower-
region) LSPs. When the specified packet LSP bandwidths are much smaller
than the lower-region LSP bandwidth, the one-hop lower-region LSP
between the source-destination IP routers is not fully utilized. In
order to utilize network resources, low-speed higher-region LSPs should
be efficiently merged at some transit nodes into high-speed lower-region
LSPs. There are two main options for routing a higher-region LSP over
the optical network: single hop routes or multiple hop routes. Whether
low-speed traffic streams should be groomed or not depends on the net-
work resource availability such as the number of available wavelengths
and the number of available ports in the packet-switching fabric.
Lower-region LSPs form network topology, which is used for routing of
higher-region LSPs. The network topology formed by lower-region LSPs is
called a virtual network topology.
There are on-line and off-line approaches for configuring virtual net-
work topologies. Since it is difficult to predict traffic demands
Oki et al. [Page 4]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
precisely, the on-line approach may be realistic and useful in utilizing
the network resources more fully and maximizing the revenue from the
given resources.
Virtual network topology optimization may be performed in a distributed
manner, or in a centralized manner.
3.2. Interworking between GMPLS and IP/MPLS networks
IP/MPLS and GMPLS networks will coexist at some point in time in the
migration process. Such IP/MPLS nodes that do not support GMPLS proto-
cols must also operate with GMPLS networks. Migration scenarios from
IP/MPLS networks to GMPLS networks that illustrate the issues for rout-
ing and signaling are presented in [OKI-INTERWORK].
Consider an MPLS LSP that is established from an MPLS source node to an
MPLS destination node via a GMPLS network. The GMPLS network provides a
link, which is a GMPLS LSP, for the MPLS LSP. The GMPLS LSP is consid-
ered as a lower-region LSP, while the MPLS LSP is considered as a
higher-region LSP. In other words, a lower-region LSP is established by
GMPLS nodes, while a higher-region LSP is established by MPLS nodes.
3.3. Triggered lower-region LSP setup
3.3.1. Overview of triggered lower-region LSP setup
In the triggered lower-region LSP setup, higher-region traffic increase
or a higher-region LSP setup invokes the lower-region LSP setup when the
lower-region LSP setup is needed. The triggered lower-region LSP setup
are required in the following cases.
Case 1: When a higher-region LSP setup is processed, a new lower-region
LSP is setup,
Case 1-1: because there is no lower-region LSP whose residual bandwidth
is larger than the requested higher-region bandwidth, or
Case 1-2: because the network provider judges that establishing a new
lower-region LSP is more cost effective than using an existing lower-
region LSP even it is available.
Case 2: higher-region traffic volume increases, but a lower-region
residual LSP bandwidth is not enough to transmit the higher-region traf-
fic with a certain quality of service.
Note that the higher-region traffic and LSP includes ones in IP/MPLS
networks, as is described in Section 3.2.
Oki et al. [Page 5]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
Since the lower-region LSP setup triggered by higher-region traffic
increase (case 2) can be classified in a subset of a scenario of the
virtual network topology reconfiguration, as described in Section 3.4,
only the lower-region LSP setup triggered by the higher-region LSP setup
(case 1) is considered in Section 3.3.
Figure 1 shows the framework of multi-region routing as an one-line
approach. If a new lower-region LSP must be setup to support higher-
region LSP routing, a lower-region LSP setup request is invoked and
lower-region LSP routing is performed. The lower-region LSP-routing
result is returned back to the higher-region LSP routing procedure for
confirmation of its acceptability. This process is iterated until the
desired result is obtained. If successful, the multi-region routing pro-
cedure notifies its acceptance for the higher-region LSP setup request.
+-------------------------------+
|Higher-region LSP setup request|
+-------------------------------+
|
v
+-----------------+ +-------------------------------+
| Lower-region |--------->|Higher-region LSP accept/reject|
| LSP routing|<---------+-------------------------------+
+-----------------+ ^
| |
v |
+------------------------------+ |
|Lower-region LSP setup request| |
+------------------------------+ |
| |
v |
+------------------------+ |
|Lower-region LSP routing|---------+
+------------------------+
Figure 1 Framework for multi-region routing.
In multi-region routing, there are mainly two possible routing policies.
When a new higher-region LSP is requested with specified bandwidth, both
policies first try to allocate the new requested higher-region LSP to an
existing lower-region LSP that directly connects the source and destina-
tion nodes. If such a lower-region LSP (existing) is not available, the
two policies adopt different procedures. Policy 1 tries to find a series
of available existing lower-region LSPs with two or more hops that con-
nect source and destination nodes. On the other hand, policy 2 tries to
setup a new one hop lower-region LSP between source and destination
nodes.
Which policy should be adopted depends on available network resources
Oki et al. [Page 6]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
such as link and port resources. PCE should judge whether new lower-
region LSPs should be established, or existing lower-region LSPs should
be used. PCE provides LSP routes for both region LSPs if it is neces-
sary. The LSP routes may be specified as a "explicit" or " loose"
route.
3.3.2. Two approaches for triggered lower-region LSP setup
To achieve triggered lower-region LSP setups, there are two possible
approaches.
The first approach is that PCE participates in both route calculation of
both region LSPs and the management of hierarchical signaling including
initiating the lower-region LSP setup. The GMPLS node does not have to
manage multi-region hierarchical signaling. The GMPLS node can handle
two single-region LSP establishments separately.
The second approach is that PCE participates only in the route calcula-
tion of both region LSPs and does not have to handle the management of
hierarchical signaling. The GMPLS node handles multi-region hierarchical
signaling.
More messages between the GMPLS node and PCE need to be defined in the
first approach than the second approach. In the first approach, PCE more
involves in multi-region traffic engineering, but the GMPLS node less
does. Vice versa in the second approach.
A GMPLS node that supports only single-region traffic engineering
prefers adopting the first approach to adopting the second approach.
This is because a single-region supporting GMPLS node can support multi-
region traffic engineering in corporation with PCE as long as PCE inter-
faces are implemented.
3.4. Virtual network topology reconfiguration
A virtual network topology should be optimized, or reconfigured, so that
a set of traffic demand is efficiently carried, considering available
network resources such as ports and links.
Procedures of a virtual network topology reconfiguration includes lower-
region LSP setup, lower-region LSP release, and higher-region LSP
rerouting according to the virtual network topology change.
A virtual network topology reconfiguration are required in the following
cases.
Oki et al. [Page 7]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
Case 1: higher-region traffic volume increases, but a lower-region
residual LSP bandwidth is not enough to transmit the higher-region traf-
fic with a certain quality of service.
Case 2: Since higher-region traffic volumes between source and destina-
tion nodes are dramatically fluctuated, a fixed virtual network topology
is not able to provide a certain quality of service, or it is no longer
an optimal topology. For example, traffic fluctuations may occur due to
differences of user traffic patterns between day and night times. It may
occur due to appearances of new services or new servers.
Case 3: Topology configurations are changed when physical nodes or links
are added/deleted, or when nodal configurations are changed.
Case 4: Since network failures occur, existing lower-region LSPs are not
available. Higher-region traffic transmitted through the fault lower-
region LSPs need to be rerouted. If no possible reroute to save the
traffic is found on a current virtual network topology, a virtual net-
work topology reconfiguration is necessary.
Thus, a virtual network topology reconfiguration may be triggered by
traffic demand change (cases 1-2), by topology change (case 3), or by
network failure (case 4).
3.5. Single-region traffic engineering
Single-region traffic engineering is a subset of multi-region traffic
engineering, as is described in Sections 3.1-3.4. PCE supports to pro-
vide an LSP route request in a single-region environment.
4. PCE placement scenarios
A PCE is placed in a GMPLS network in two possible ways. One way is
that each PCE is attached to each GMPLS node, as shown in Figure 2. A
PCE behaves as a part of functions in a corresponding GMPLS node. PCE
processing load does not dramatically increase as the number of nodes in
the networks increases. Traffic engineering is performed in a dis-
tributed manner.
Distributed traffic engineering mechanisms, including traffic engineer-
ing database (TEDB) synchronization between PCEs, algorithm synchroniza-
tion, LSP establishment/release sequence synchronization, etc., are
needed. Detail TEDB information is described in Section 5.2
Oki et al. [Page 8]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
+---+ +---+ +---+
|PCE| |PCE| |PCE|
+---+ +---+ +---+
| | |
+----------+ +----------+ +----------+
|GMPLS node|--|GMPLS node|--|GMPLS node|
+----------+ +----------+ +----------+
Figure 2 PCE that communicates with one GMPLS node.
The other way is that a PCE communicates with more than one GMPLS node,
as shown in Figure 3. PCE processing load may increase as the number of
nodes attached to PCE. In an extreme case that there are one PCE in the
GMPLS network, traffic engineering may be performed in a centralized
manner.
+---+
+-----------|PCE|-----------+
| +---+ |
| | |
+----------+ +----------+ +----------+
|GMPLS node|--|GMPLS node|--|GMPLS node|
+----------+ +----------+ +----------+
Figure 3 PCE that communicates with more than one GMPLS node.
5. PCE functional scenarios
5.1. Overview
PCE provides functions of traffic engineering in GMPLS and IP/MPLS net-
works. In IP/MPLS networks, PCE provides MPLS LSP routes with con-
straints. In GMPLS networks, PCE provides GMPLS LSP routes and optimal
virtual network topology reconfiguration control, and judges on whether
a new lower-region LSP should be established when a higher-region LSP is
requested. PCE also handles interworking between GMPLS and IP/MPLS net-
works, both of which will coexist at some point during the migration
process.
A PCE model in terms of inputs to PCE and outputs from PCE are as fol-
lows.
+------+ +---+ +-------+
|Inputs|--->|PCE|--->|Outputs|
+------+ +---+ +-------+
Figure 4 Inputs and outputs of PCE
Inputs to PCE and outputs from PCE for possible scenarios are summarized
as follows.
Oki et al. [Page 9]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
Inputs to PCE
Updated information of TE links (see Section 5.2)
Route request triggered by higher-region LSP setup
Route request in single-region TE
Lower-region LSP setup response
Lower-region LSP release response
Higher-region LSP route change response
Trigger of traffic demand change
Trigger of topology change
Trigger of network failure
Outputs from PCE:
Route response
Lower-region LSP setup request
Lower-region LSP release request
Higher-region LSP route change request
Inputs and outputs for each scenarios are described in Sections 5.3-5.5.
5.2. Collection of TE-link information
PCE collects TE-link information, which is stored in its TEDB. First,
TE-link information may be collected by using routing protocols of
OSPF/IS-IS [RFC2338][RFC3630][GMPLS-OSPF] if PCE is configured as a
OSPF/ISIS peer node. Second, TE-link information may be collected by
monitoring link-state advertisement passing through some control-plane
links between/among OSPF/ISIF peer nodes. Third, TE-link information may
be collected by specific protocols between PCE and a GMPLS node such as
SNMP or new ones. In the collection of TE-link information that is not
included in link-sate advertisements, the third mechanism should be
adopted. Otherwise, routing protocols needs to be extended to advitise
TE-link information that is not included in link-sate advertisements.
A GMPLS node keeps information of LSPs as TE links. The TE-link informa-
tion includes,
Interface identifiers
Reserved bandwidth
GMPLS specific parameters such as switch type, encoding type, and GPID
Protection type and link type
SRLG
LSP identification (LSP ID, Tunnel ID, SA, DA)
Measured traffic volume passing through LSP
LSP route, etc.
Five items from the top are advertised as TE-link information with
Opaque LSA [GMPLS-OSPF] when the LSP is considered as FA LSP, but others
are not.
Oki et al. [Page 10]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
PCE calculates a route based on constraints and TE-link information. PCE
provides the route with the GMPLS node when it is requested. PCE calcu-
lates a virtual network topology to be reconfigured based on TE-link
information and controls LSP establishments and releases to reconfigure
a virtual network topology.
5.3. Triggered lower-region LSP setup
As described in Section 2, there are two possible approach in the lower-
region LSP setup triggered by higher-region LSP setup.
5.3.1. First approach
An example of the first approach is in the following [OKI-GTEP].
PCE GMPLS node
| |
| Route Request |
|<----------------------------------------|
| |
| Lower-region LSP Setup Request* |
|---------------------------------------->|
| |
| Lower-region LSP Setup Response* |
|<----------------------------------------|
| |
| Route Response |
|---------------------------------------->|
| |
*LSP Setup Request/LSP Setup Response appear only when the lower-region
LSP needs to be established.
Figure 4 Triggered lower-region LSP setup procedure (first approach)
Step 1: The GMPLS node is requested to setup a higher-region LSP. The
node may be an ingress node, or an transit node from the high-region
LSP's point of view.
Step 2: If at least one condition in the following is satisfied, go to
Step 3. 1. In the case of an ingress node, Explicit Route is not speci-
fied. In the case of a transit node, Explicit Route Object is included
in a Path Message. 2. When Explicit Route is specified, the next hop
node is specified as Loose. 3. When Explicit Route is specified and the
next hop node is specified as "Strict", there is no TE-link that satis-
fies constraints such as bandwidth between the node and the next hop
Oki et al. [Page 11]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
node. Otherwise, go to Step 7.
Step 3. The GMPLS node requests a route of the higher-region LSP to PCE
Step 4. PCE requires PCE to setup a lower-region LSP if it is necessary.
Otherwise, go to Step 6.
Step 5. The GMPLS node tries to setup the lower-layer LSP and returns
the result whether the LSP setup succeeds to PCE. When the LSP setup
succeeds, the result includes LSP_TUNNEL_IF_ID for the FA LSP. LSP_TUN-
NEL_IF_ID is used to specify Explicit Route Object for the higher-region
LSP.
Step 6. PCE responds to the GMPLS node by specifying the route of the
higher-region LSP. The specified route is formatted as Explicit Route
Object that is carried in a Path message. Then, go to Step 7.
Step 7. Signaling procedure starts as an ingress node, or continues as
an transit node for the higher-region LSP, according to the route speci-
fied by PCE.
Inputs to PCE and outputs from PCE are as follows.
Inputs to PCE:
Updated information of TE links (see Section 5.2)
Route request triggered by higher-region LSP setup with constraints of
LSP to be setup including GMPLS specific parameters
Lower-region LSP setup response
Outputs from PCE:
Route response
Lower-region LSP setup request with constraints of LSP to be setup
including GMPLS specific parameters
5.3.2. Second approach
PCE GMPLS node
| |
| Route Request |
|<----------------------------------------|
| |
| Route Response |
|---------------------------------------->|
| |
Figure 5 Triggered lower-region LSP setup procedure (Second approach)
Oki et al. [Page 12]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
An example of the second approach is in the following.
Step 1: The GMPLS node is requested to setup an higher-region LSP. The
node may be an ingress node, or an transit node from the high-region
LSP's point of view.
Step 2: If at least one condition in the following is satisfied, go to
Step 3. 1. In the case of an ingress node, Explicit Route is not speci-
fied. In the case of a transit node, Explicit Route Object is included
in a Path Message. 2. When Explicit Route is specified, the next hop
node is specified as Loose. 3. When Explicit Route is specified and the
next hop node is specified as "Strict", there is no TE-link that satis-
fies constraints such as bandwidth between the node and the next hop
node. Otherwise, go to Step 6.
Step 3. The GMPLS node requests a route of the higher-region LSP. to
PCE.
Step 4. PCE provides the route of the higher-region LSP. If necessary,
it also provides the route of a lower-region LSP to be setup.
Step 5. In case of the necessary of the lower-region LSP establishment,
the GMPLS node tries to setup the lower-region LSP, according the speci-
fied route provided by PCE. If signaling procedure of the lower-region
LSP setup is completed, go to Step 6.
Step 6. Signaling procedure of the higher-region LSP starts as an
ingress node, or continues as an transit node for the higher-region LSP,
according to the route specified by PCE.
Inputs to PCE and outputs from PCE are as follows.
Inputs to PCE:
Updated information of TE links (see Section 5.2)
Route request triggered by higher-region LSP setup with constraints of
LSP to be setup including GMPLS specific parameters
Outputs from PCE:
Route response
5.4. Virtual network topology reconfiguration
A virtual network topology reconfiguration may be triggered by traffic
demand change, by topology change, or by network failure. In the fol-
lowing subsections, each reconfiguration is described.
Oki et al. [Page 13]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
5.4.1. Virtual network topology reconfiguration triggered by traffic
demand change
To achieve virtual topology reconfiguration triggered by traffic demand
change, the following functions of PCE and the GMPLS node are needed.
The virtual topology reconfiguration trigger may be issued by a GMPLS
node or PCE.
PCE collects TE-link information, periodically, when some values are
changed, or when some measured values exceed specified thresholds at
GMPLS nodes.
The calculation of the reconfigured virtual topology may be performed
periodically, when some LSP values are changes, or threshold-based.
PCE controls virtual network topology reconfiguration according to the
calculation results.
When a virtual network topology is reconfigured, "make-before-break"
procedures for established higher-region LSPs should be adopted so that
service disruption can be avoided.
PCE GMPLS node
| |
| Traffic demand change trigger |
|<----------------------------------------|
| |
| Lower-region LSP setup request* |
| Lower-regoin LSP release request* |
| Higher-region LSP route change request* |
|---------------------------------------->|
| |
| Lower-region LSP setup response* |
| Lower-regoin LSP release response* |
| Higher-region LSP route change response*|
|<----------------------------------------|
| |
*The order of these requests and responses depends on reconfiguration
procedures.
Figure 6 Virtual network topology reconfiguration triggered by traffic
demand change issued by GMPLS node
Oki et al. [Page 14]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
PCE GMPLS node
| |
| Traffic demand change trigger |
|---------------------------------------->|
| |
| Lower-region LSP setup request* |
| Lower-regoin LSP release request* |
| Higher-region LSP route change request* |
|---------------------------------------->|
| |
| Lower-region LSP setup response* |
| Lower-regoin LSP release response* |
| Higher-region LSP route change response*|
|<----------------------------------------|
| |
*The order of these requests and responses depends on reconfiguration
procedures.
Figure 7 Virtual network topology reconfiguration triggered by traffic
demand change issued by PCE
Inputs to PCE and outputs from PCE are as follows.
Inputs to PCE:
Updated information of TE links (see Section 5.2)
Traffic demand change trigger issued by GMPLS node
Lower-region LSP setup response
Lower-region LSP release response
Higher-region LSP route change response
Outputs from PCE:
Traffic demand change trigger issued by PCE
Lower-region LSP setup request
Lower-region LSP release request
Higher-region LSP route change request
5.4.2. Virtual network topology reconfiguration triggered by topology
change
The calculation of the reconfigured virtual topology is performed when
topology is changed. The virtual topology reconfiguration trigger may be
issued by a GMPLS node or PCE.
PCE controls virtual network topology reconfiguration according to the
calculation results.
Oki et al. [Page 15]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
When a virtual network topology is reconfigured, "make-before-break"
procedures for established LSPs should be adopted so that service dis-
ruption can be avoided.
PCE GMPLS node
| |
| Network topology change trigger |
|<----------------------------------------|
| |
| Lower-region LSP setup request* |
| Lower-regoin LSP release request* |
| Higher-region LSP route change request* |
|---------------------------------------->|
| |
| Lower-region LSP setup response* |
| Lower-regoin LSP release response* |
| Higher-region LSP route change response*|
|<----------------------------------------|
| |
*The order of these requests and responses depends on reconfiguration
procedures.
Figure 8 Virtual network topology reconfiguration triggered by traffic
demand change issued by GMPLS node
PCE GMPLS node
| |
| Network topology change trigger |
|---------------------------------------->|
| |
| Lower-region LSP setup request* |
| Lower-regoin LSP release request* |
| Higher-region LSP route change request* |
|---------------------------------------->|
| |
| Lower-region LSP setup response* |
| Lower-regoin LSP release response* |
| Higher-region LSP route change response*|
|<----------------------------------------|
| |
*The order of these requests and responses depends on reconfiguration
procedures.
Figure 9 Virtual network topology reconfiguration triggered by traffic
demand change issued by PCE
Oki et al. [Page 16]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
Inputs to PCE and outputs from PCE are as follows.
Inputs to PCE:
Updated information of TE links (see Section 5.2)
Topology change trigger issued by GMPLS node
Lower-region LSP setup response
Lower-region LSP release response
Higher-region LSP route change response
Outputs from PCE:
Topology change trigger issued by PCE
Lower-region LSP setup request
Lower-region LSP release request
Higher-region LSP route change request
5.4.3. Virtual network topology reconfiguration triggered by network
failure
When network failure occurs, virtual topology reconfiguration should be
performed as fast as possible so that the degradation of network perfor-
mance can be avoided. The virtual topology reconfiguration trigger may
be issued by a GMPLS node or PCE.
Procedures of the virtual network topology reconfiguration is similar to
that triggered by traffic demand change and topology change, but the
network failure triggered operation requires urgent actions as a emer-
gent case.
PCE GMPLS node
| |
| Network failure change trigger |
|<----------------------------------------|
| |
| Lower-region LSP setup request* |
| Lower-regoin LSP release request* |
| Higher-region LSP route change request* |
|---------------------------------------->|
| |
| Lower-region LSP setup response* |
| Lower-regoin LSP release response* |
| Higher-region LSP route change response*|
|<----------------------------------------|
| |
*The order of these requests and responses depends on reconfiguration
procedures.
Oki et al. [Page 17]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
Figure 10 Virtual network topology reconfiguration triggered by traffic
demand change issued by GMPLS node
PCE GMPLS node
| |
| Network failure change trigger |
|---------------------------------------->|
| |
| Lower-region LSP setup request* |
| Lower-regoin LSP release request* |
| Higher-region LSP route change request* |
|---------------------------------------->|
| |
| Lower-region LSP setup response* |
| Lower-regoin LSP release response* |
| Higher-region LSP route change response*|
|<----------------------------------------|
| |
*The order of these requests and responses depends on reconfiguration
procedures.
Figure 11 Virtual network topology reconfiguration triggered by traffic
demand change issued by PCE
Inputs to PCE and outputs from PCE are as follows.
Inputs to PCE:
Updated information of TE links (see Section 5.2)
Network failure change trigger issued by GMPLS node
Lower-region LSP setup response
Lower-region LSP release response
Higher-region LSP route change response
Outputs from PCE:
Lower-region LSP setup request
Lower-region LSP release request
Higher-region LSP route change request
5.5. Single-region traffic engineering
Oki et al. [Page 18]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
PCE GMPLS node
| |
| Route Request |
|<---------------------------|
| |
| Route Response |
|--------------------------->|
| |
Figure 12 Single-region traffic engineering
An example of the single-layer LSP route request procedure is in the
following.
Step 1. The GMPLS node is requested to setup an LSP.
Step 2. The GMPLS node requests a route of the LSP to PCE.
Step 3. PCE sends the GMPLS node the LSP route.
Inputs to PCE and outputs from PCE are as follows.
Inputs to PCE:
Updated information of TE links (see Section 5.2)
Route request in single-region TE
Outputs from PCE:
Route response
6. PCE Requirements
6.1. Triggered lower-region LSP setup
Lower-region LSP setup triggered by the high-layer LSP setup should be
supported. When the higher-layer LSP is setup, PCE should judge whether
new lower-layer LSPs should be established as forwarding adjacency LSPs
(FA-LSPs), or existing lower-layer LSPs should be used as FA-LSPs. PCE
provides LSP routes for both layer LSPs if it is necessary. The LSP
routes may be specified as a "explicit" or " loose" route.
To achieve triggered lower-region LSP setups, there are two possible
approaches.
The first approach is that PCE participates in both route calculation of
both region LSPs and the management of hierarchical signaling including
Oki et al. [Page 19]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
initiating the lower-region LSP setup. The GMPLS node does not have to
manage multi-region hierarchical signaling. The GMPLS node can handle
two single-region LSP establishments separately.
The second approach is that PCE participates only in the route calcula-
tion of both region LSPs and does not have to handle the management of
hierarchical signaling. The GMPLS node handles multi-region hierarchical
signaling.
More messages between the GMPLS node and PCE need to be defined in the
first approach than the second approach. In the first approach, PCE more
involves in multi-region traffic engineering, but the GMPLS node less
does. Vice versa in the second approach.
A GMPLS node that supports only single-region traffic engineering
prefers adopting the first approach to adopting the second approach.
This is because a single-region supporting GMPLS node can support multi-
region traffic engineering in corporation with PCE as long as PCE inter-
faces are implemented.
6.2. Virtual network topology reconfiguration
Virtual network topology reconfigurations triggered by traffic demand
change, by topology change, and by network failure should be supported.
When a virtual network topology is reconfigured triggered by traffic
demand change and by topology change, "make-before-break" procedures for
established LSPs should be adopted so that service disruption can be
avoided.
When network failure occurs, virtual topology reconfiguration should be
performed as fast as possible so that the degradation of network perfor-
mance can be avoided.
6.3. Single-region traffic engineering
Single-region traffic engineering is a subset of multi-region traffic
engineering. PCE should support to provide an LSP route request in a
single-region environment.
6.4. Constraints of the route calculation to PCE
A GMPLS node should provide constraints for LSP setups for PCE, when the
GMPLS node requests a route of the LSP to PCE.
Oki et al. [Page 20]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
Constraints for LSP setups should include GMPLS specific parameters.
Example of the GMPLS specific parameters are a switch type, encoding
type, GPID, bandwidth, protection type, and link type, which are
included in a generalized label request object [RFC3471][RFC3473].
When PCE fails to provide an route that doest not satisfy the con-
straints, PCE should optionally includes suggested routes but does not
completely satisfy the constraints that enable to find a route. In MPLS
networks, [MPLS-COMP] describes examples of relaxation of alternative
constraints such as bandwidth and protection type. In GMPLS networks,
relaxation of alternative constraints such as switching type, encoding
type, GPID, and SRLG should be extended.
6.5. Collection of TE-link information
PCE should collect TE-link information. A part of TE-link information is
able to be obtained by using routing protocols of OSPF/IS-IS. However, A
part of TE-link information that is not included in link-sate advertise-
ments is not able to be collected with the routing protocols. Such TE-
link information should be collected by specific protocols between PCE
and a GMPLS node.
A GMPLS node should keep information of LSPs as TE links. The TE-link
information includes,
Reserved LSP bandwidth
GMPLS specific parameters such as switch type, encoding type, GPID,
Protection type and link type
Measured traffic volume passing through LSP
LSP route, etc.
The first and second items are advertised as TE-link information with
Opaque LSA [GMPLS-OSPF] when the LSP is considered as FA LSP, but others
are not.
PCE should collect all TE-link information in the manageable network
domain. The LSP information that is stored in LSP database of each GMPLS
node should be reported to PCE in a timely manner. LSP database should
be updated after LSP establishment/release. A large volume of TE-link
information data should be transferred with reliability.
6.6. PCE scalability
In GMPLS multi-region network environments, traffic engineering becomes
more complicated, compared with that in single-region network environ-
ments. Complicated TE algorithms should not degrade PCE scalability in
terms of processing capability.
Oki et al. [Page 21]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
6.7. Interworking GMPLS and IP/MPLS networks
PCE should support interworking GMPLS and IP/MPLS networks, both of
which will coexist at some point during the migration process [OKI-
INTERWORK].
6.8. Synchronization of TEDBs in PCE and in GMPLS node
TEDB in PCEs and GMPLS nodes should be synchronized consistently.
6.9. Fault-tolerant PCEs
PCE should be fault tolerant.
7. Nodal requirements related to PCE
7.1. PCE request mode
7.1.1. PCE mandatory request mode
A GMPLS node should have a mandatory request mode where it must request
PCE to calculate a route to the destination node whenever the route
needs to be obtained. In this mode, the GMPLS node should not calculate
the route with its own CSPF engine.
7.1.2. PCE normal request mode
A GMPLS node should have a normal request mode. Consider that a GMPLS
node receives a Path message including Explicit Route Object. The next
hop node is specified as "Strict", but there is no TE link that satis-
fies constraints. The GMPLS node should not issue a Path Error Massage
to the upstream node without inquiring the possibility of a lower-region
LSP establishment with PCE.
The GMPLS node should request the possibility of a lower-region LSP
establishment with PCE. The lower-region LSP establishment suggested by
PCE should be consistent with the explicit route of the higher-region
LSP.
Oki et al. [Page 22]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
7.2. Network stability in terms of PCE
When a GMPLS node is not able to find any available PCE in a managed
network domain, a GMPLS node should act as a non-PCE mode.
Any PCE failure should not affect data-plane transmission that is
already serviced.
8. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any Intel-
lectual Property Rights or other rights that might be claimed to pertain
to the implementation or use of the technology described in this docu-
ment 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 assur-
ances 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 propri-
etary 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 stan-
dard. Please address the information to the IETF at ietf-ipr@ietf.org.
9. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668.
10. References
[GMPLS-ARC] E. Mannie, "Generalized Multi-Protocol Label Switching
Architecture," IETF draft, draft-ietf-ccamp-gmpls-architecture-07.txt,
May 2003.
[RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional
Description," RFC 3471 , Jan. 2003.
Oki et al. [Page 23]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
[RFC3473] P. Ashwood-Smith et al, "Generalized MPLS Signaling - RSVP-TE
Extensions," RFC 3473, Jan. 2003.
[RFC2338] J. Moy, "OSPF Version 2," RFC 2328.
[RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to OSPF
Version 2," RFC 3630.
[GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of
Generalized MPLS," IETF draft, draft-ietf-ccamp-ospf-gmpls-exten-
sions-12.txt, Oct. 2003. (working in progress)
[RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in
Resource ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC 3477.
(working in progress)
[MRN] D. Papadimitriou et al., "Generalized MPLS Architecture for Multi-
Region Networks, draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, Feb.
2004. (working in progress)
[LSP-HIERARCHY] K. Kompella and Y. Rekhter, "LSP Hierarchy with General-
ized MPLS TE," draft-ietf-mpls-lsp-hierarchy-08.txt, Sep. 2002. (working
in progress)
[MPLS-COMP] JP Vasseur et al., "RSVP Path computation request and reply
messages," IETF draft, draft-vasseur-mpls-computation-rsvp-03, June
2002.
[OKI-GTEP] E. Oki et al., "Generalized Traffic Engineering Protocol",
IETF draft, draft-oki-ccamp-gtep-00.txt, April 2004.
[OKI-INTERWORK] E. Oki et al, "Migrating from IP/MPLS to GMPLS net-
works," IETF draft, draft-oki-ccamp-gmpls-ip-interworking-03.txt, June
2004.
11. Authors' Address
Eiji Oki
NTT Corporation
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp
Takashi Kurimoto
NTT Corporation
3-9-11 Midori-cho,
Oki et al. [Page 24]
Oki et al. draft-oki-pce-gmpls-req-00.txt July 2004
Musashino-shi, Tokyo 180-8585, Japan
Email: kurimoto.takashi@lab.ntt.co.jp
Ichiro Inoue
NTT Corporation
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: inoue.ichiro@lab.ntt.co.jp
Kohei Shiomoto
NTT Corporation
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp
Oki et al. [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-23 09:05:37 |