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/ |