draft-ietf-ccamp-gmpls-mln-eval-03.txt   draft-ietf-ccamp-gmpls-mln-eval-04.txt 
Network Working Group J.L. Le Roux (Ed.) Network Working Group J.L. Le Roux (Ed.)
Internet Draft France Telecom Internet Draft France Telecom
Category: Informational Category: Informational
Expires: January 2008 D. Papadimitriou (Ed.) Expires: May 2008 D. Papadimitriou (Ed.)
Alcatel-Lucent Alcatel-Lucent
November 2007
Evaluation of existing GMPLS Protocols against Multi Layer Evaluation of existing GMPLS Protocols against Multi Layer
and Multi Region Networks (MLN/MRN) and Multi Region Networks (MLN/MRN)
draft-ietf-ccamp-gmpls-mln-eval-03.txt draft-ietf-ccamp-gmpls-mln-eval-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction................................................3 1. Introduction................................................3
2. MLN/MRN Requirements Overview...............................4 2. MLN/MRN Requirements Overview...............................4
3. Analysis....................................................4 3. Analysis....................................................4
3.1. Multi Layer Network Aspects.................................4 3.1. Multi Layer Network Aspects.................................4
3.1.1. Support for Virtual Network Topology Reconfiguration........4 3.1.1. Support for Virtual Network Topology Reconfiguration........4
3.1.1.1. Control of FA-LSPs Setup/Release..........................5 3.1.1.1. Control of FA-LSPs Setup/Release..........................5
3.1.1.2. Virtual TE-Links..........................................6 3.1.1.2. Virtual TE-Links..........................................6
3.1.1.3. Traffic Disruption Minimization During FA Release.........7 3.1.1.3. Traffic Disruption Minimization During FA Release.........7
3.1.1.4. Stability.................................................8 3.1.1.4. Stability.................................................7
3.1.2. Support for FA-LSP Attributes Inheritance...................8 3.1.2. Support for FA-LSP Attributes Inheritance...................8
3.1.3. FA-LSP Connectivity Verification............................8 3.1.3. FA-LSP Connectivity Verification............................8
3.2. Specific Aspects for Multi-Region Networks..................9 3.2. Specific Aspects for Multi-Region Networks..................8
3.2.1. Support for Multi-Region Signaling..........................9 3.2.1. Support for Multi-Region Signaling..........................8
3.2.2. Advertisement of Internal Adaptation Capabilities...........9 3.2.2. Advertisement of Adjustment Capacities......................9
4. Evaluation Conclusion......................................12 4. Evaluation Conclusion......................................12
5. Security Considerations....................................12 5. Security Considerations....................................12
6. Acknowledgments............................................12 6. Acknowledgments............................................13
7. References.................................................13 7. References.................................................13
7.1. Normative..................................................13 7.1. Normative..................................................13
7.2. Informative................................................13 7.2. Informative................................................13
8. Editors' Addresses:........................................14 8. Editors' Addresses:........................................14
9. Contributors' Addresses:...................................14 9. Contributors' Addresses:...................................14
10. Intellectual Property Statement............................15 10. Intellectual Property Statement............................15
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to Generalized MPLS (GMPLS) extends MPLS to handle multiple switching
handle multiple switching technologies: packet switching (PSC), technologies: packet switching, layer-2 switching, TDM switching,
layer-two switching (L2SC), TDM switching (TDM), wavelength switching wavelength switching, and fiber switching (see [RFC3945]). The
(LSC) and fiber switching (FSC) (see [RFC 3945]). Interface Switching Capability (ISC) concept is introduced for
these switching technologies and is designated as follows: PSC
A data plane layer is a collection of network resources capable of (Packet Switch Capable), L2SC (Layer-2 Switch Capable), TDM (Time
terminating and/or switching data traffic of a particular format. For Division Multiplex capable), LSC (Lambda Switch Capable), and FSC
example, LSC, TDM VC-11 and TDM VC-4-64c are three different layers. (Fiber Switch Capable). The representation, in a GMPLS control
A network comprising transport nodes with different data plane plane, of a switching technology domain is referred to as a region
switching layers controlled by a single GMPLS control plane instance [RFC4206]. A switching type describes the ability of a node to
is called a Multi-Layer Network (MLN). forward data of a particular data plane technology, and uniquely
identifies a network region.
A GMPLS switching type (PSC, TDM, etc.) describes the ability of a
node to forward data of a particular data plane technology, and
uniquely identifies a control plane region. The notion of Label
Switched Path (LSP) Region is defined in [RFC4206]. A network
comprised of multiple switching types (for example PSC and TDM)
controlled by a single GMPLS control plane instance is called a
Multi-Region Network (MRN).
Note that the region is a control plane only concept. That is, layers
of the same region share the same switching technology and,
therefore, need the same set of technology-specific signaling
objects.
Note that a MRN is necessarily a MLN, but not vice versa, as a MLN A data plane switching layer describes a data plane switching
may consist of multiple data plane layers of the same switching granularity level. For example, LSC, TDM VC-11 and TDM VC-4-64c are
technology. Hence, in the following, we use the term "layer" if the three different layers. [MLN-REQ] defines a Multi Layer Network (MLN)
mechanism discussed applies equally to layers and regions (for to be a TE domain comprising multiple data plane switching layers
example VNT, virtual TE-link, etc.), and we specifically use the term either of the same ISC (e.g. TDM) or different ISC (e.g. TDM and
"region" if the mechanism applies only to the support of a MRN. PSC) and controlled by a single GMPLS control plane instance.
[MLN-REQ] further define a particular case of MLNs. A Multi Region
Network (MRN) is defined as a TE domain supporting at least two
different switching types (e.g., PSC and TDM), either hosted on the
same device or on different ones, and under the control of a single
GMPLS control plane instance.
The objectives of this document are to evaluate existing GMPLS The objectives of this document are to evaluate existing GMPLS
mechanisms and protocols ([RFC 3945], [RFC4202], [RFC3471, mechanisms and protocols ([RFC 3945], [RFC4202], [RFC3471,
[RFC3473]]) against the requirements for MLN and MRN, defined in [RFC3473]]) against the requirements for MLN and MRN, defined in
[MLN-REQ]. From this evaluation, we identify several areas where [MLN-REQ]. From this evaluation, we identify several areas where
additional protocol extensions and modifications are required to meet additional protocol extensions and modifications are required to meet
these requirements, and provide guidelines for potential extensions. these requirements, and provide guidelines for potential extensions.
A summary of MLN/MRN requirements is provided in section 2. Then A summary of MLN/MRN requirements is provided in section 2. Then
section 3 evaluates for each of these requirements, whether current section 3 evaluates for each of these requirements, whether current
skipping to change at page 4, line 21 skipping to change at page 4, line 12
This document uses terminologies defined in [RFC3945], [RFC4206], and This document uses terminologies defined in [RFC3945], [RFC4206], and
[MLN-REQ]. [MLN-REQ].
2. MLN/MRN Requirements Overview 2. MLN/MRN Requirements Overview
Section 5 of [MLN-REQ] lists a set of functional requirements for Section 5 of [MLN-REQ] lists a set of functional requirements for
Multi Layer/Region Networks (MLN/MRN). These requirements are Multi Layer/Region Networks (MLN/MRN). These requirements are
summarized below, and a mapping with sub-sections of [MLN-REQ] is summarized below, and a mapping with sub-sections of [MLN-REQ] is
provided. provided.
Here is the list of requirements that apply to MLN: Here is the list of requirements that apply to MLN (and thus to MRN):
- Support for robust Virtual Network Topology (VNT) - Support for robust Virtual Network Topology (VNT)
reconfiguration. This implies the following requirements: reconfiguration. This implies the following requirements:
- Optimal control of Forwarding Adjacency LSP (FA-LSP) - Optimal control of Forwarding Adjacency LSP (FA-LSP)
setup and release (section 5.8.1 of [MLN-REQ]); setup and release (section 5.8.1 of [MLN-REQ]);
- Support for virtual TE-links (section 5.8.2 of [MLN- - Support for virtual TE-links (section 5.8.2 of [MLN-
REQ]); REQ]);
- Traffic Disruption minimization during FA-LSP release - Traffic Disruption minimization during FA-LSP release
(section 5.5 of [MLN-REQ]); (section 5.5 of [MLN-REQ]);
- Stability (section 5.4 of [MLN-REQ]); - Stability (section 5.4 of [MLN-REQ]);
skipping to change at page 4, line 43 skipping to change at page 4, line 34
- Support for FA-LSP attributes inheritance (section 5.6 of - Support for FA-LSP attributes inheritance (section 5.6 of
[MLN-REQ]); [MLN-REQ]);
- Support for FA-LSP data plane connectivity verification - Support for FA-LSP data plane connectivity verification
(section 5.9 of [MLN-REQ]); (section 5.9 of [MLN-REQ]);
Here is the list of requirements that apply to MRN only: Here is the list of requirements that apply to MRN only:
- Support for Multi-Region signaling (section 5.7 of [MLN-REQ]); - Support for Multi-Region signaling (section 5.7 of [MLN-REQ]);
- Advertisement of the adaptation capabilities and resources - Advertisement of the adjustment capacity (section 5.2 of
(section 5.2 of [MLN-REQ]); [MLN-REQ]);
3. Analysis 3. Analysis
3.1. Multi Layer Network Aspects 3.1. Multi Layer Network Aspects
3.1.1. Support for Virtual Network Topology Reconfiguration 3.1.1. Support for Virtual Network Topology Reconfiguration
A set of lower-layer FA-LSPs provides a Virtual Network Topology A set of lower-layer FA-LSPs provides a Virtual Network Topology
(VNT) to the upper-layer [MLN-REQ]. By reconfiguring the VNT (FA-LSP (VNT) to the upper-layer [MLN-REQ]. By reconfiguring the VNT (FA-LSP
setup/release) according to traffic demands between source and setup/release) according to traffic demands between source and
skipping to change at page 5, line 36 skipping to change at page 5, line 31
- Policing and scheduling of VNT resources with regard to - Policing and scheduling of VNT resources with regard to
traffic demands and usage (that is, decision to setup/release traffic demands and usage (that is, decision to setup/release
FA-LSPs); The functional component in charge of this function FA-LSPs); The functional component in charge of this function
is called a VNT Manager (VNTM). is called a VNT Manager (VNTM).
- VNT Paths Computation according to TE topology, and - VNT Paths Computation according to TE topology, and
potentially taking into account the old (existing) VNT to potentially taking into account the old (existing) VNT to
minimize changes. The Functional component in charge of VNT minimize changes. The Functional component in charge of VNT
computation may be distributed on network elements or may be computation may be distributed on network elements or may be
centralized on an external tool (such as a Path Computation performed on an external tool (such as a Path Computation
Element (PCE), [RFC4655]). Element (PCE), [RFC4655]).
- FA-LSP setup/release. - FA-LSP setup/release.
GMPLS routing protocols provide TE topology discovery. GMPLS routing protocols provide TE topology discovery.
GMPLS signaling protocols allow setting up/releasing FA-LSPs. GMPLS signaling protocols allow setting up/releasing FA-LSPs.
VNT Management functions (resources policing/scheduling, decision to VNTM functions (resources policing/scheduling, decision to
setup/release FA-LSPs, FA-LSP configuration) are out of the scope of setup/release FA-LSPs, FA-LSP configuration) are out of the scope of
GMPLS protocols. Such functionalities can be achieved directly on GMPLS protocols. Such functionalities can be achieved directly on
layer border LSRs, or through one or more external tools. When an layer border LSRs, or through one or more external tools. When an
external tool is used, an interface is required between the VNTM and external tool is used, an interface is required between the VNTM and
the network elements so as to setup/releases FA-LSPs. This could use the network elements so as to setup/release FA-LSPs. This could use
standard management interfaces such as [RFC4802]. standard management interfaces such as [RFC4802].
The set of traffic demands of the upper layer is required for the The set of traffic demands of the upper layer is required for the
VNT Manager to take decisions to setup/release FA-LSPs. Such VNT Manager to take decisions to setup/release FA-LSPs. Such
traffic demands include satisfied demands, for which one or more traffic demands include satisfied demands, for which one or more
upper layer LSP have been successfully satisfied, as well as upper layer LSP have been successfully setup, as well as unsatisfied
unsatisfied demands and future demands, for which no upper layer LSP demands and future demands, for which no upper layer LSP has been
has been setup yet. The collection of such information is beyond the setup yet. The collection of such information is beyond the scope of
scope of GMPLS protocols, but may be partially inferred from GMPLS protocols. Note that it may be partially inferred from
parameters carried in GMPLS signaling or advertised in GMPLS routing. parameters carried in GMPLS signalling or advertised in GMPLS routing.
Finally, the computation of FA-LSPs that form the VNT can be Finally, the computation of FA-LSPs that form the VNT can be
performed directly on layer border LSRs or on an external tool (such performed directly on layer border LSRs or on an external tool (such
as a Path Computation Element (PCE), [RFC4655]), and this is as a Path Computation Element (PCE), [RFC4655]), and this is
independent of the location of the VNTM. VNT computation is triggered independent of the location of the VNTM.
by the VNTM (for example, when the path computation is externalized
on a PCE, the VNTM acts as Path Computation Client (PCC)).
Hence, to summarize, no GMPLS protocol extensions are required to Hence, to summarize, no GMPLS protocol extensions are required to
control FA-LSP setup/release. control FA-LSP setup/release.
3.1.1.2. Virtual TE-Links 3.1.1.2. Virtual TE-Links
A Virtual TE-link is a TE-link between two upper layer nodes that is A Virtual TE-link is a TE-link between two upper layer nodes that is
not actually associated with a fully provisioned FA-LSP in a lower not actually associated with a fully provisioned FA-LSP in a lower
layer. A Virtual TE-link represents the potentiality to setup an FA- layer. A Virtual TE-link represents the potentiality to setup an FA-
LSP in the lower layer to support the TE-link that has been LSP in the lower layer to support the TE-link that has been
advertised. A Virtual TE-link is advertised as any TE-link, following advertised. A Virtual TE-link is advertised as any TE-link, following
the rules in [RFC4206] defined for fully provisioned TE-links. In the rules in [RFC4206] defined for fully provisioned TE-links. In
particular, the flooding scope of a Virtual TE-link is within an IGP particular, the flooding scope of a Virtual TE-link is within an IGP
area, as is the case for any TE-link. area, as is the case for any TE-link.
If an upper-layer LSP attempts (through a signalling message) to make If an upper-layer LSP attempts (through a signalling message) to make
use of a Virtual TE-link, the underlying FA-LSP is immediately use of a Virtual TE-link, the underlying FA-LSP is immediately
signalled and provisioned in the process known as triggered signalled and provisioned (provided there are available resources in
signaling. the lower layer) in the process known as triggered signaling.
The use of Virtual TE-links has two main advantages: The use of Virtual TE-links has two main advantages:
- Flexibility: allows the computation of an LSP path using TE-links - Flexibility: allows the computation of an LSP path using TE-links
without needing to take into account the actual provisioning without needing to take into account the actual provisioning
status of the corresponding FA-LSP in the lower layer; status of the corresponding FA-LSP in the lower layer;
- Stability: allows stability of TE-links in the upper layer, while - Stability: allows stability of TE-links in the upper layer, while
avoiding wastage of bandwidth in the lower layer, as data plane avoiding wastage of bandwidth in the lower layer, as data plane
connections are not established until they are actually needed. connections are not established until they are actually needed.
skipping to change at page 8, line 18 skipping to change at page 8, line 11
frequent changes. In this context robustness of the VNT is defined as frequent changes. In this context robustness of the VNT is defined as
the capability to smooth the impact of these changes and avoid their the capability to smooth the impact of these changes and avoid their
subsequent propagation. subsequent propagation.
Guaranteeing VNT stability is out of the scope of GMPLS protocols and Guaranteeing VNT stability is out of the scope of GMPLS protocols and
relies entirely on the capability of the TE and VNT management relies entirely on the capability of the TE and VNT management
algorithms to minimize routing perturbations. This requires that the algorithms to minimize routing perturbations. This requires that the
algorithms takes into account the old VNT when computing a new VNT, algorithms takes into account the old VNT when computing a new VNT,
and try to minimize the perturbation. and try to minimize the perturbation.
A full mesh of upper-layer LSPs MAY be created between every pair of Note that a full mesh of lower-layer LSPs may be created between
border nodes between the upper and lower layers. The merit of a full every pair of border nodes between the upper and lower layers. The
mesh of upper-layer LSPs is that it provides stability to the upper merit of a full mesh of lower-layer LSPs is that it provides
layer routing. That is, forwarding table used in the upper layer is stability to the upper layer routing. That is, forwarding table used
not impacted if the VNT undergoes changes. Further, there is always in the upper layer is not impacted if the VNT undergoes changes.
full reachability and immediate access to bandwidth to support LSPs Further, there is always full reachability and immediate access to
in the upper layer. But it also has significant drawbacks, since it bandwidth to support LSPs in the upper layer. But it also has
requires the maintenance of n^2 RSVP-TE sessions, which may be quite significant drawbacks, since it requires the maintenance of n^2 RSVP-
CPU and memory consuming (scalability impact). Also this may lead to TE sessions, which may be quite CPU and memory consuming (scalability
significant bandwidth wastage. Note that the use of virtual TE-links impact). Also this may lead to significant bandwidth wastage. Note
solves the bandwidth wastage issue, and may reduce the control plane that the use of virtual TE-links solves the bandwidth wastage issue,
overload. and may reduce the control plane overload.
3.1.2. Support for FA-LSP Attributes Inheritance 3.1.2. Support for FA-LSP Attributes Inheritance
When a FA TE Link is advertised, its parameters are inherited from When a FA TE Link is advertised, its parameters are inherited from
the parameters of the FA-LSP, and specific inheritance rules are the parameters of the FA-LSP, and specific inheritance rules are
applied. applied.
This relies on local procedures and policies and is out of the scope This relies on local procedures and policies and is out of the scope
of GMPLS protocols. Note that this requires that both head-end and of GMPLS protocols. Note that this requires that both head-end and
tail-end of the FA-LSP are driven by same policies. tail-end of the FA-LSP are driven by same policies.
skipping to change at page 9, line 19 skipping to change at page 9, line 7
There are actually several cases where a transit node could choose There are actually several cases where a transit node could choose
between multiple SCs to be used for a lower region FA-LSP: between multiple SCs to be used for a lower region FA-LSP:
- ERO expansion with loose hops: The transit node has to expand the - ERO expansion with loose hops: The transit node has to expand the
path, and may have to select among a set of lower region SCs. path, and may have to select among a set of lower region SCs.
- Multi-SC TE link: When the ERO of a FA LSP, included in the ERO of - Multi-SC TE link: When the ERO of a FA LSP, included in the ERO of
an upper region LSP, comprises a multi-SC TE-link, the region an upper region LSP, comprises a multi-SC TE-link, the region
border node has to select among these SCs. border node has to select among these SCs.
Existing GMPLS signalling procedures does not allow solving this Existing GMPLS signalling procedures do not allow solving this
ambiguous choice of SC that may be used along a given path. ambiguous choice of SC that may be used along a given path.
Hence an extension to GMPLS signalling has to be defined to indicate Hence an extension to GMPLS signalling has to be defined to indicate
the SC(s) that can be used and the SC(s) that cannot be used along the SC(s) that can be used and the SC(s) that cannot be used along
the path. the path.
3.2.2. Advertisement of Internal Adaptation Capabilities 3.2.2. Advertisement of Adjustment Capacities
In the MRN context, nodes supporting more than one switching In the MRN context, nodes supporting more than one switching
capability on at least one interface are called Hybrid nodes ([MLN- capability on at least one interface are called Hybrid nodes ([MLN-
REQ]). Hybrid nodes contain at least two distinct switching elements REQ]). Conceptually, hybrid nodes can be viewed as containing at
that are interconnected by internal links to provide adaptation least two distinct switching elements interconnected by internal
between the supported switching capabilities. These internal links links which provide adjustment between the supported switching
have finite capacities and must be taken into account when computing capabilities. These internal links have finite capacities and must be
the path of a multi-region TE-LSP. The advertisement of the internal taken into account when computing the path of a multi-region TE-LSP.
adaptation capability is required as it provides critical information The advertisement of the adjustment capacities is required as it
when performing multi-region path computation. provides critical information when performing multi-region path
computation.
The term adjustment capacity refers to the property of a hybrid node
to interconnect different switching capabilities it provides though
its external interfaces [MLN-REQ]. This information allows path
computation to select an end-to-end multi-region path that includes
links of different switching capabilities that are joined by LSRs
that can adapt the signal between the links.
Figure 1a below shows an example of hybrid node. The hybrid node has Figure 1a below shows an example of hybrid node. The hybrid node has
two switching elements (matrices), which support here TDM and PSC two switching elements (matrices), which support here TDM and PSC
switching respectively. The node terminates two PSC and TDM ports switching respectively. The node has two PSC and TDM ports (port1 and
(port1 and port2 respectively). It also has internal link connecting port2 respectively). It also has internal link connecting the two
the two switching elements. switching elements.
The two switching elements are internally interconnected in such a The two switching elements are internally interconnected in such a
way that it is possible to terminate some of the resources of the TDM way that it is possible to terminate some of the resources of the TDM
port 2 and provide through them adaptation for PSC traffic, port 2 and provide through them adjustment for PSC traffic,
received/sent over the internal PSC interface (#b). Two ways are received/sent over the internal PSC interface (#b). Two ways are
possible to set up PSC LSPs (port 1 or port 2). Available resources possible to set up PSC LSPs (port 1 or port 2). Available resources
advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover advertisement e.g. Unreserved and Min/Max LSP Bandwidth should cover
both ways. both ways.
Network element Network element
............................. .............................
: -------- : : -------- :
PSC : | PSC | : PSC : | PSC | :
Port1-------------<->---|#a | : Port1-------------<->---|#a | :
: +--<->---|#b | : : +--<->---|#b | :
: | -------- : : | -------- :
TDM : | ---------- : : | ---------- :
+PSC : +--<->--|#c TDM | : TDM : +--<->--|#c TDM | :
Port2 ------------<->--|#d | : Port2 ------------<->--|#d | :
: ---------- : : ---------- :
:............................ :............................
Figure 1a. Hybrid node. Figure 1a. Hybrid node.
Port 1 and Port 2 can be grouped together thanks to internal DWDM, to Port 1 and Port 2 can be grouped together thanks to internal DWDM, to
result in a single interface: Link 1. This is illustrated in figure result in a single interface: Link 1. This is illustrated in figure
1b below. 1b below.
skipping to change at page 11, line 7 skipping to change at page 10, line 52
Let's assume that all interfaces are STM16 (with VC4-16c capable Let's assume that all interfaces are STM16 (with VC4-16c capable
as Max LSP bandwidth). After, setting up several PSC LSPs via port #a as Max LSP bandwidth). After, setting up several PSC LSPs via port #a
and setting up and terminating several TDM LSPs via port #d and port and setting up and terminating several TDM LSPs via port #d and port
#b, there is only 155 Mb capacities still available on port #b. #b, there is only 155 Mb capacities still available on port #b.
However a 622 Mb capacity remains on port #a and VC4-5c capacity on However a 622 Mb capacity remains on port #a and VC4-5c capacity on
port #d. port #d.
When computing the path for a new VC4-4c TDM LSP, one must know, that When computing the path for a new VC4-4c TDM LSP, one must know, that
this node cannot terminate this LSP, as there is only 155Mb still this node cannot terminate this LSP, as there is only 155Mb still
available for TDM-PSC adaptation. Hence the internal TDM-PSC available for TDM-PSC adjustment. Hence the TDM-PSC adjustment
adaptation capability must be advertised. capacity must be advertised.
With current GMPLS routing [RFC4202] this advertisement is possible With current GMPLS routing [RFC4202] this advertisement is possible
if link bundling is not used and if two TE-links are advertised for if link bundling is not used and if two TE-links are advertised for
link1: link1:
We would have the following TE-link advertisements: We would have the following TE-link advertisements:
TE-link 1 (port 1): TE-link 1 (port 1):
- ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb - ISCD sub-TLV: PSC with Max LSP bandwidth = 622Mb
- Unreserved bandwidth = 622Mb. - Unreserved bandwidth = 622Mb.
TE-Link 2 (port 2): TE-Link 2 (port 2):
- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb, - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 155 Mb,
- Unreserved bandwidth (equivalent): 777 Mb. - Unreserved bandwidth (equivalent): 777 Mb.
The ISCD 2 in TE-link 2 represents actually the internal TDM-PSC The ISCD 2 in TE-link 2 represents actually the TDM-PSC adjustment
adaptation capability. capacity.
However if for obvious scalability reasons link bundling is done then However if for obvious scalability reasons link bundling is done then
the adaptation capability information is lost with current GMPLS the adjustment capacity information is lost with current GMPLS
routing, as we have the following TE-link advertisement: routing, as we have the following TE-link advertisement:
TE-link 1 (port 1 + port 2): TE-link 1 (port 1 + port 2):
- ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c, - ISCD #1 sub-TLV: TDM with Max LSP bandwidth = VC4-4c,
- ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb, - ISCD #2 sub-TLV: PSC with Max LSP bandwidth = 622 Mb,
- Unreserved bandwidth (equivalent): 1399 Mb. - Unreserved bandwidth (equivalent): 1399 Mb.
With such TE-link advertisement an element computing the path of a With such TE-link advertisement an element computing the path of a
VC4-4c LSP cannot know that this LSP cannot be terminated on the VC4-4c LSP cannot know that this LSP cannot be terminated on the
node. node.
Thus current GMPLS routing can support the advertisement of the Thus current GMPLS routing can support the advertisement of the
internal adaptation capability but this precludes performing link adjustment capacities but this precludes performing link bundling and
bundling and thus faces significant scalability limitations. thus faces significant scalability limitations.
Hence, GMPLS routing must be extended to meet this requirement. This Hence, GMPLS routing must be extended to meet this requirement. This
could rely on the advertisement of the internal adaptation capability could rely on the advertisement of the adjustment capacities as a new
as a new TE link attribute (that would complement the Interface TE link attribute (that would complement the Interface Switching
Switching Capability Descriptor TE-link attribute). Capability Descriptor TE-link attribute).
Note: Multiple ISCDs MAY be associated to a single switching Note: Multiple ISCDs MAY be associated to a single switching
capability. This can be performed to provide e.g. for TDM interfaces capability. This can be performed to provide e.g. for TDM interfaces
the Min/Max LSP Bandwidth associated to each (set of) layer for that the Min/Max LSP Bandwidth associated to each (set of) layer for that
switching capability. As an example, an interface associated to TDM switching capability. As an example, an interface associated to TDM
switching capability and supporting VC-12 and VC-4 switching, can be switching capability and supporting VC-12 and VC-4 switching, can be
associated one ISCD sub-TLV or two ISCD sub-TLVs. In the first case, associated one ISCD sub-TLV or two ISCD sub-TLVs. In the first case,
the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to the Min LSP Bandwidth is set to VC-12 and the Max LSP Bandwidth to
VC-4. In the second case, the Min LSP Bandwidth is set to VC-12 and VC-4. In the second case, the Min LSP Bandwidth is set to VC-12 and
the Max LSP Bandwidth to VC-12, in the first ISCD sub-TLV; and the the Max LSP Bandwidth to VC-12, in the first ISCD sub-TLV; and the
Min LSP Bandwidth is set to VC-4 and the Max LSP Bandwidth to VC-4, Min LSP Bandwidth is set to VC-4 and the Max LSP Bandwidth to VC-4,
in the second ISCD sub-TLV. Hence, in the first case, as long as the in the second ISCD sub-TLV. Hence, in the first case, as long as the
Min LSP Bandwidth is set to VC-12 (and not VC-4) and in the second Min LSP Bandwidth is set to VC-12 (and not VC-4) and in the second
case, as long as the first ISCD sub-TLV is advertised there is case, as long as the first ISCD sub-TLV is advertised there is
sufficient capacity across that interface to setup a VC-12 LSP." sufficient capacity across that interface to setup a VC-12 LSP.
4. Evaluation Conclusion 4. Evaluation Conclusion
Most of the required MLN/MRN functions will rely on mechanisms and Most of the required MLN/MRN functions will rely on mechanisms and
procedures that are out of the scope of the GMPLS protocols, and thus procedures that are out of the scope of the GMPLS protocols, and thus
do not require any GMPLS protocol extensions. They will rely on local do not require any GMPLS protocol extensions. They will rely on local
procedures and policies, and on specific TE mechanisms and procedures and policies, and on specific TE mechanisms and
algorithms. algorithms.
As regards Virtual Network Topology (VNT) computation and As regards Virtual Network Topology (VNT) computation and
skipping to change at page 12, line 37 skipping to change at page 12, line 33
- GMPLS signaling extension for the setup/deletion of - GMPLS signaling extension for the setup/deletion of
the virtual TE-links; the virtual TE-links;
- GMPLS routing and signaling extension for graceful TE-link - GMPLS routing and signaling extension for graceful TE-link
deletion; deletion;
- GMPLS signaling extension for constrained multi-region - GMPLS signaling extension for constrained multi-region
signalling (SC inclusion/exclusion); signalling (SC inclusion/exclusion);
- GMPLS routing extension for the advertisement of the - GMPLS routing extension for the advertisement of the
internal adaptation capability of hybrid nodes. adjustment capacities of hybrid nodes.
5. Security Considerations 5. Security Considerations
This document specifically addresses GMPLS control plane [MLN-REQ] sets out the security requirements for operating a MLN or
functionality for MLN/MRN in the context of a single administrative MRN. These requirements are, in general, no different from the
control plane partition and hence does not introduce additional security requirements for operating any GMPLS network. As such, the
security threats beyond those described in [RFC3945]. GMPLS protocols already provide adequate security features. An
evaluation of the security features for GMPLS networks may be found
in [MPLS-SEC], and where issues or further work is identified by that
document, new security features or procedures for the GMPLS protocols
will need to be developed.
[MLN-REQ] also identifies that where the separate layers of a MLN/MRN
network are operated as different administrative domains, additional
security considerations may be given to the mechanisms for allowing
inter-layer LSP setup. However, this document is explicitly limited
to the case where all layers under GMPLS control are part of the same
administrative domain.
Lastly, as noted in [MLN-REQ], it is expected that solution documents
will include a full analysis of the security issues that any protocol
extensions introduce.
6. Acknowledgments 6. Acknowledgments
We would like to thank Julien Meuric, Igor Bryskin and Adrian Farrel We would like to thank Julien Meuric, Igor Bryskin and Adrian Farrel
for their useful comments. for their useful comments.
Thanks also to Question 14 of Study Group 15 of the ITU-T for their
thoughtful review.
7. References 7. References
7.1. Normative 7.1. Normative
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF [RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005. Technology", BCP 79, RFC 3979, March 2005.
[RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label [RFC3945] Mannie, E., et. al. "Generalized Multi-Protocol Label
Switching Architecture", RFC 3945, October 2004 Switching Architecture", RFC 3945, October 2004
skipping to change at page 13, line 46 skipping to change at page 14, line 11
[RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with [RFC4206] K. Kompella and Y. Rekhter, "LSP hierarchy with
generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy,
RFC4206, October 2005. RFC4206, October 2005.
[GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic [GR-SHUT] Ali, Z., Zamfir, A., "Graceful Shutdown in MPLS Traffic
Engineering Network", draft-ietf-ccamp-mpls-graceful- Engineering Network", draft-ietf-ccamp-mpls-graceful-
shutdown, work in progress. shutdown, work in progress.
[RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in [RFC4872] Lang, Rekhter, Papadimitriou, "RSVP-TE Extensions in
support of End-to-End Generalized Multi-Protocol Label support of End-to-End Generalized Multi-Protocol Label
Switching (GMPLS)-based Recovery", RFC4872, July 2007. Switching (GMPLS)-based Recovery", RFC4872, May 2007.
[VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network [VNTM] Oki, Le Roux, Farrel, "Definition of Virtual Network
Topology Manager (VNTM) for PCE-based Inter-Layer MPLS Topology Manager (VNTM) for PCE-based Inter-Layer MPLS
and GMPLS Traffic Engineering", draft-oki-pce-vntm-def, and GMPLS Traffic Engineering", draft-oki-pce-vntm-def,
work in progress. work in progress.
[IW-MIG-FMWK]Shiomoto, K et al., "Framework for IP/MPLS-GMPLS [IW-MIG-FMWK]Shiomoto, K et al., "Framework for IP/MPLS-GMPLS
interworking in support of IP/MPLS to GMPLS migration", interworking in support of IP/MPLS to GMPLS migration",
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in
progress. progress.
[RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions", [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions",
RFC3473, January 2003. RFC3473, January 2003.
[RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based [RFC4655] Farrel, A., Vasseur, J.-P., Ash,J., "A PCE based
Architecture", RFC4655, August 2006. Architecture", RFC4655, August 2006.
[RFC4802] Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802, [RFC4802] Nadeau, T., Farrel, A., "GMPLS TE MIB", RFC4802,
February 2007. February 2007.
8. Editors' Addresses [MPLS-SEC] Fang, et al. "Security Framework for MPLS and GMPLS
Networks draft-fang-mpls-gmpls-security-framework, work
in progress.
8. Editors' Addresses:
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex, France 22307 Lannion Cedex, France
Email: jeanlouis.leroux@orange-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel-Lucent Alcatel-Lucent
Francis Wellensplein 1, Francis Wellensplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Email: dimitri.papadimitriou@alcatel-lucent.be Email: dimitri.papadimitriou@alcatel-lucent.be
9. Contributors' Addresses 9. Contributors' Addresses:
Deborah Brungard Deborah Brungard
AT&T AT&T
Rm. D1-3C22 - 200 S. Laurel Ave. Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ, 07748 USA Middletown, NJ, 07748 USA
E-mail: dbrungard@att.com E-mail: dbrungard@att.com
Eiji Oki Eiji Oki
NTT NTT
3-9-11 Midori-Cho 3-9-11 Midori-Cho
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Kohei Shiomoto Kohei Shiomoto
NTT NTT
3-9-11 Midori-Cho 3-9-11 Midori-Cho
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
 End of changes. 36 change blocks. 
100 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/