draft-ietf-ccamp-gmpls-mln-reqs-08.txt | draft-ietf-ccamp-gmpls-mln-reqs-09.txt | |||
---|---|---|---|---|
Network Working Group Kohei Shiomoto (NTT) | Network Working Group Kohei Shiomoto (NTT) | |||
Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) | Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) | |||
Intended Status: Informational Jean-Louis Le Roux (France Telecom) | Intended Status: Informational Jean-Louis Le Roux (France Telecom) | |||
Martin Vigoureux (Alcatel-Lucent) | Martin Vigoureux (Alcatel-Lucent) | |||
Deborah Brungard (AT&T) | Deborah Brungard (AT&T) | |||
Expires: July 2008 January 2008 | ||||
Requirements for GMPLS-Based Multi-Region and | Requirements for GMPLS-Based Multi-Region and | |||
Multi-Layer Networks (MRN/MLN) | Multi-Layer Networks (MRN/MLN) | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt | draft-ietf-ccamp-gmpls-mln-reqs-09.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 | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 2, line 5 | skipping to change at page 2, line 5 | |||
Most of the initial efforts to utilize Generalized MPLS (GMPLS) | Most of the initial efforts to utilize Generalized MPLS (GMPLS) | |||
have been related to environments hosting devices with a single | have been related to environments hosting devices with a single | |||
switching capability. The complexity raised by the control of such | switching capability. The complexity raised by the control of such | |||
data planes is similar to that seen in classical IP/MPLS networks. | data planes is similar to that seen in classical IP/MPLS networks. | |||
By extending MPLS to support multiple switching technologies, GMPLS | By extending MPLS to support multiple switching technologies, GMPLS | |||
provides a comprehensive framework for the control of a multi- | provides a comprehensive framework for the control of a multi- | |||
layered network of either a single switching technology or multiple | layered network of either a single switching technology or multiple | |||
switching technologies. | switching technologies. | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
In GMPLS, a switching technology domain defines a region, and a | In GMPLS, a switching technology domain defines a region, and a | |||
network of multiple switching types is referred to in this document | network of multiple switching types is referred to in this document | |||
as a Multi-Region Network (MRN). When referring in general to a | as a Multi-Region Network (MRN). When referring in general to a | |||
layered network, which may consist of either a single or multiple | layered network, which may consist of either a single or multiple | |||
regions, this document uses the term, Multi-Layer Network (MLN). | regions, this document uses the term, Multi-Layer Network (MLN). | |||
This document defines a framework for GMPLS based multi-region / | This document defines a framework for GMPLS based multi-region / | |||
multi-layer networks and lists a set of functional requirements. | multi-layer networks and lists a set of functional requirements. | |||
Table of Contents | Table of Contents | |||
1. Introduction .................................................... | 1. Introduction.................................................3 | |||
1.1. Scope ......................................................... | 1.1. Scope......................................................4 | |||
2. Conventions Used in this Document ............................... | 2. Conventions Used in this Document............................5 | |||
2.1. List of Acronyms .............................................. | 2.1. List of Acronyms...........................................5 | |||
3. Positioning ..................................................... | 3. Positioning..................................................6 | |||
3.1. Data Plane Layers and Control Plane Regions ................... | 3.1. Data Plane Layers and Control Plane Regions................6 | |||
3.2. Service Layer Networks .. ..................................... | 3.2. Service Layer Networks.....................................6 | |||
3.3. Vertical and Horizontal Interaction and Integration ........... | 3.3. Vertical and Horizontal Interaction and Integration........7 | |||
3.4. Motivation .................................................... | 3.4. Motivation.................................................8 | |||
4. Key Concepts of GMPLS-Based MLNs and MRNs ....................... | 4. Key Concepts of GMPLS-Based MLNs and MRNs....................9 | |||
4.1. Interface Switching Capability ................................ | 4.1. Interface Switching Capability.............................9 | |||
4.2. Multiple Interface Switching Capabilities ..................... | 4.2. Multiple Interface Switching Capabilities.................10 | |||
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes ..... | 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes.11 | |||
4.3. Integrated Traffic Engineering (TE) and Resource Control ...... | 4.3. Integrated Traffic Engineering (TE) and Resource Control..11 | |||
4.3.1. Triggered Signaling ......................................... | 4.3.1. Triggered Signaling.....................................12 | |||
4.3.2. FA-LSPs ..................................................... | 4.3.2. FA-LSPs.................................................12 | |||
4.3.3. Virtual Network Topology (VNT) .............................. | 4.3.3. Virtual Network Topology (VNT)..........................13 | |||
5. Requirements .................................................... | 5. Requirements................................................14 | |||
5.1. Handling Single-Switching and Multi-Switching-Type-Capable | 5.1. Handling Single-Switching and Multi-Switching-Type-Capable | |||
Nodes ....................................................... | Nodes.....................................................14 | |||
5.2. Advertisement of the Available Adjustment Resource ............ | 5.2. Advertisement of the Available Adjustment Resource........14 | |||
5.3. Scalability ................................................... | 5.3. Scalability...............................................15 | |||
5.4. Stability ..................................................... | 5.4. Stability.................................................16 | |||
5.5. Disruption Minimization ....................................... | 5.5. Disruption Minimization...................................16 | |||
5.6. LSP Attribute Inheritance ..................................... | 5.6. LSP Attribute Inheritance.................................16 | |||
5.7. Computing Paths With and Without Nested Signaling ............. | 5.7. Computing Paths With and Without Nested Signaling.........17 | |||
5.8. LSP Resource Utilization ...................................... | 5.8. LSP Resource Utilization..................................18 | |||
5.8.1. FA-LSP Release and Setup .................................... | 5.8.1. FA-LSP Release and Setup................................18 | |||
5.8.2. Virtual TE-Links ............................................ | 5.8.2. Virtual TE-Links........................................19 | |||
5.9. Verification of the LSPs ...................................... | 5.9. Verification of the LSPs..................................20 | |||
6. Security Considerations ......................................... | 6. Security Considerations.....................................21 | |||
7. IANA Considerations ............................................ | 7. IANA Considerations.........................................21 | |||
8. Acknowledgements ................................................ | 8. Acknowledgements............................................21 | |||
9. References ...................................................... | 9. References..................................................21 | |||
9.1. Normative Reference ........................................... | 9.1. Normative Reference.......................................21 | |||
9.2. Informative References ........................................ | 9.2. Informative References....................................22 | |||
10. Authors' Addresses.........................................23 | ||||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | 11. Contributors' Addresses....................................24 | |||
12. Intellectual Property Considerations.......................24 | ||||
10. Authors' Addresses ............................................. | 13. Full Copyright Statement...................................25 | |||
11. Contributors' Addresses ........................................ | ||||
12. Intellectual Property Considerations ........................... | ||||
13. Full Copyright Statement ....................................... | ||||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
1. Introduction | 1. Introduction | |||
Generalized MPLS (GMPLS) extends MPLS to handle multiple switching | Generalized MPLS (GMPLS) extends MPLS to handle multiple switching | |||
technologies: packet switching, layer-2 switching, TDM switching, | technologies: packet switching, layer-2 switching, TDM switching, | |||
wavelength switching, and fiber switching (see [RFC3945]). The | wavelength switching, and fiber switching (see [RFC3945]). The | |||
Interface Switching Capability (ISC) concept is introduced for | Interface Switching Capability (ISC) concept is introduced for | |||
these switching technologies and is designated as follows: PSC | these switching technologies and is designated as follows: PSC | |||
(packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | |||
Division Multiplex capable), LSC (lambda switch capable), and FSC | Division Multiplex capable), LSC (lambda switch capable), and FSC | |||
skipping to change at page 4, line 35 | skipping to change at page 3, line 33 | |||
associated with PSC). However, more than one data plane layer can | associated with PSC). However, more than one data plane layer can | |||
be associated with the same region (e.g., both VC4 and VC12 are | be associated with the same region (e.g., both VC4 and VC12 are | |||
associated with TDM). Thus, a control plane region, identified by | associated with TDM). Thus, a control plane region, identified by | |||
its switching type value (e.g., TDM), can be sub-divided into | its switching type value (e.g., TDM), can be sub-divided into | |||
smaller granularity component networks based on "data plane | smaller granularity component networks based on "data plane | |||
switching layers". The Interface Switching Capability Descriptor | switching layers". The Interface Switching Capability Descriptor | |||
(ISCD) [RFC4202], identifying the interface switching capability | (ISCD) [RFC4202], identifying the interface switching capability | |||
(ISC), the encoding type, and the switching bandwidth granularity, | (ISC), the encoding type, and the switching bandwidth granularity, | |||
enables the characterization of the associated layers. | enables the characterization of the associated layers. | |||
In this document, we define a Multi Layer Network (MLN) to be a TE | In this document, we define a Multi Layer Network (MLN) to be a | |||
domain comprising multiple data plane switching layers either of | Traffic Engineering (TE) domain comprising multiple data plane | |||
the same ISC (e.g. TDM) or different ISC (e.g. TDM and PSC) and | switching layers either of the same ISC (e.g., TDM) or different | |||
controlled by a single GMPLS control plane instance. We further | ISC (e.g., TDM and PSC) and controlled by a single GMPLS control | |||
define a particular case of MLNs. A Multi Region Network (MRN) is | plane instance. We further define a particular case of MLNs. A | |||
defined as a TE domain supporting at least two different switching | Multi Region Network (MRN) is defined as a TE domain supporting at | |||
types (e.g., PSC and TDM), either hosted on the same device or on | least two different switching types (e.g., PSC and TDM), either | |||
different ones, and under the control of a single GMPLS control | hosted on the same device or on different ones, and under the | |||
plane instance. | control of a single GMPLS control plane instance. | |||
MLNs can be further categorized according to the distribution of | MLNs can be further categorized according to the distribution of | |||
the ISCs among the LSRs: | the ISCs among the Label Switching Routers (LSRs): | |||
- Each LSR may support just one ISC. | - Each LSR may support just one ISC. | |||
Such LSRs are known as single-switching-type-capable LSRs. | Such LSRs are known as single-switching-type-capable LSRs. | |||
The MLN may comprise a set of single-switching-type-capable LSRs | The MLN may comprise a set of single-switching-type-capable LSRs | |||
some of which support different ISCs. | some of which support different ISCs. | |||
- Each LSR may support more than one ISC at the same time. | - Each LSR may support more than one ISC at the same time. | |||
- | - Such LSRs are known as multi-switching-type-capable LSRs, and | |||
Such LSRs are known as multi-switching-type-capable LSRs, and | ||||
can be further classified as either "simplex" or "hybrid" nodes | can be further classified as either "simplex" or "hybrid" nodes | |||
as defined in Section 4.2. | as defined in Section 4.2. | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | - The MLN may be constructed from any combination of single- | |||
- | ||||
- - The MLN may be constructed from any combination of single- | ||||
switching-type-capable LSRs and multi-switching-type-capable | switching-type-capable LSRs and multi-switching-type-capable | |||
LSRs. | LSRs. | |||
Since GMPLS provides a comprehensive framework for the control of | Since GMPLS provides a comprehensive framework for the control of | |||
different switching capabilities, a single GMPLS instance may be | different switching capabilities, a single GMPLS instance may be | |||
used to control the MLN/MRN. This enables rapid service | used to control the MLN/MRN. This enables rapid service | |||
provisioning and efficient traffic engineering across all switching | provisioning and efficient traffic engineering across all switching | |||
capabilities. In such networks, TE Links are consolidated into a | capabilities. In such networks, TE Links are consolidated into a | |||
single Traffic Engineering Database (TED). Since this TED contains | single Traffic Engineering Database (TED). Since this TED contains | |||
the information relative to all the different regions and layers | the information relative to all the different regions and layers | |||
existing in the network, a path across multiple regions or layers | existing in the network, a path across multiple regions or layers | |||
can be computed using this TED. Thus optimization of network | can be computed using this TED. Thus optimization of network | |||
resources can be achieved across the whole MLN/MRN. | resources can be achieved across the whole MLN/MRN. | |||
Consider, for example, a MRN consisting of packet- switch capable | Consider, for example, a MRN consisting of packet- switch capable | |||
routers and TDM cross-connects. Assume that a packet LSP is routed | routers and TDM cross-connects. Assume that a packet Label Switched | |||
between source and destination packet-switch capable routers, and | Path (LSP) is routed between source and destination packet-switch | |||
that the LSP can be routed across the PSC-region (i.e., utilizing | capable routers, and that the LSP can be routed across the PSC- | |||
only resources of the packet region topology). If the performance | region (i.e., utilizing only resources of the packet region | |||
objective for the packet LSP is not satisfied, new TE links may be | topology). If the performance objective for the packet LSP is not | |||
created between the packet-switch capable routers across the TDM- | satisfied, new TE links may be created between the packet-switch | |||
region (for example, VC-12 links) and the LSP can be routed over | capable routers across the TDM-region (for example, VC-12 links) | |||
those TE links. Furthermore, even if the LSP can be successfully | and the LSP can be routed over those TE links. Furthermore, even if | |||
established across the PSC-region, TDM hierarchical LSPs across the | the LSP can be successfully established across the PSC-region, TDM | |||
TDM region between the packet-switch capable routers may be | hierarchical LSPs across the TDM region between the packet-switch | |||
established and used if doing so is necessary to meet the | capable routers may be established and used if doing so is | |||
operator's objectives for network resources availability (e.g., | necessary to meet the operator's objectives for network resources | |||
link bandwidth.The same considerations hold when VC4 LSPs are | availability (e.g., link bandwidth). The same considerations hold | |||
provisioned to provide extra flexibility for the VC12 and/or VC11 | when VC4 LSPs are provisioned to provide extra flexibility for the | |||
layers in an MLN. | VC12 and/or VC11 layers in an MLN. | |||
Sections 3 and 4 of this document provide further background | ||||
information of the concepts and motivation behind multi-region and | ||||
multi-layer networks. Section 5 presents detailed requirements for | ||||
protocols used to implement such networks. | ||||
1.1. Scope | 1.1. Scope | |||
This document describes the requirements to support multi-region/ | Early sections of this document describe the motivations and | |||
multi-layer networks. There is no intention to specify solution- | reasoning that require the development and deployment of MRN/MLN. | |||
specific and/or protocol elements in this document. The | Later sections of this document set out the required features that | |||
applicability of existing GMPLS protocols and any protocol | the GMPLS control plane must offer to support MRN/MLN. There is no | |||
extensions to the MRN/MLN is addressed in separate documents [MRN- | intention to specify solution- specific and/or protocol elements in | |||
EVAL]. | this document. The applicability of existing GMPLS protocols and | |||
any protocol extensions to the MRN/MLN is addressed in separate | ||||
documents [MRN-EVAL]. | ||||
This document covers the elements of a single GMPLS control plane | This document covers the elements of a single GMPLS control plane | |||
instance controlling multiple layers within a given TE domain. A | instance controlling multiple layers within a given TE domain. A | |||
control plane instance can serve one, two or more layers. Other | control plane instance can serve one, two or more layers. Other | |||
possible approaches such as having multiple control plane instances | possible approaches such as having multiple control plane instances | |||
serving disjoint sets of layers are outside the scope of this | serving disjoint sets of layers are outside the scope of this | |||
document. It is most probable that such a MLN or MRN would be | document. It is most probable that such a MLN or MRN would be | |||
operated by a single Service Provider, but this document does not | operated by a single Service Provider, but this document does not | |||
exclude the possibility of two layers (or regions) being under | exclude the possibility of two layers (or regions) being under | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
different administrative control (for example, by different Service | different administrative control (for example, by different Service | |||
Providers that share a single control plane instance) where the | Providers that share a single control plane instance) where the | |||
administrative domains are prepared to share a limited amount of | administrative domains are prepared to share a limited amount of | |||
information. | information. | |||
For such TE domain to interoperate with edge nodes/domains | For such TE domain to interoperate with edge nodes/domains | |||
supporting non-GMPLS interfaces (such as those defined by other | supporting non-GMPLS interfaces (such as those defined by other | |||
SDOs), an interworking function may be needed. Location and | SDOs), an interworking function may be needed. Location and | |||
specification of this function are outside the scope of this | specification of this function are outside the scope of this | |||
document (because interworking aspects are strictly under the | document (because interworking aspects are strictly under the | |||
responsibility of the interworking function). | responsibility of the interworking function). | |||
This document assumes that the interconnection of adjacent MRN/MLN | This document assumes that the interconnection of adjacent MRN/MLN | |||
TE domains makes use of [RFC4726] when their edges also support | TE domains makes use of [RFC4726] when their edges also support | |||
inter- domain GMPLS RSVP-TE extensions. | inter- domain GMPLS RSVP-TE extensions. | |||
2. Conventions Used in this Document | 2. Conventions Used in this Document | |||
Although this is not a protocol specification, the key words | Although this is not a protocol specification, the key words "MUST", | |||
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", | "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD | |||
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used in | NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used in this | |||
this document to highlight requirements, and are to be interpreted | document to highlight requirements, and are to be interpreted as | |||
as described in RFC 2119 [RFC2119]. | described in RFC 2119 [RFC2119]. | |||
2.1. List of Acronyms | 2.1. List of Acronyms | |||
ERO: Explicit Route Object | ||||
FA: Forwarding Adjacency | FA: Forwarding Adjacency | |||
FA-LSP: Forwarding Adjacency Label Switched Path | FA-LSP: Forwarding Adjacency Label Switched Path | |||
FSC: Fiber Switching Capable | FSC: Fiber Switching Capable | |||
ISC: Interface Switching Capability | ISC: Interface Switching Capability | |||
ISCD: Interface Switching Capability Descriptor | ISCD: Interface Switching Capability Descriptor | |||
L2SC: Layer-2 Switching Capable | L2SC: Layer-2 Switching Capable | |||
LSC: Lambda Switching Capable | LSC: Lambda Switching Capable | |||
LSP: Label Switched Path | LSP: Label Switched Path | |||
LSR: Label Switching Router | LSR: Label Switching Router | |||
MLN: Multi-Layer Network | MLN: Multi-Layer Network | |||
skipping to change at page 7, line 4 | skipping to change at page 6, line 10 | |||
TDM: Time-Division Switch Capable | TDM: Time-Division Switch Capable | |||
TE: Traffic Engineering | TE: Traffic Engineering | |||
TED: Traffic Engineering Database | TED: Traffic Engineering Database | |||
VNT: Virtual Network Topology | VNT: Virtual Network Topology | |||
3. Positioning | 3. Positioning | |||
A multi-region network (MRN) is always a multi-layer network (MLN) | A multi-region network (MRN) is always a multi-layer network (MLN) | |||
since the network devices on region boundaries bring together | since the network devices on region boundaries bring together | |||
different ISCs. A MLN, however, is not necessarily a MRN since | different ISCs. A MLN, however, is not necessarily a MRN since | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
multiple layers could be fully contained within a single region. | multiple layers could be fully contained within a single region. | |||
For example, VC12, VC4, and VC4-4c are different layers of the TDM | For example, VC12, VC4, and VC4-4c are different layers of the TDM | |||
region. | region. | |||
3.1. Data Plane Layers and Control Plane Regions | 3.1. Data Plane Layers and Control Plane Regions | |||
A data plane layer is a collection of network resources capable of | A data plane layer is a collection of network resources capable of | |||
terminating and/or switching data traffic of a particular format | terminating and/or switching data traffic of a particular format | |||
[RFC4397]. These resources can be used for establishing LSPs for | [RFC4397]. These resources can be used for establishing LSPs for | |||
traffic delivery. For example, VC-11 and VC4-64c represent two | traffic delivery. For example, VC-11 and VC4-64c represent two | |||
different layers. | different layers. | |||
From the control plane viewpoint, an LSP region is defined as a set | From the control plane viewpoint, an LSP region is defined as a set | |||
of one or more data plane layers that share the same type of | of one or more data plane layers that share the same type of | |||
switching technology, that is, the same switching type. For example, | switching technology, that is, the same switching type. For example, | |||
VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. | VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. | |||
skipping to change at page 8, line 5 | skipping to change at page 7, line 9 | |||
A service provider's network may be divided into different service | A service provider's network may be divided into different service | |||
layers. The customer's network is considered from the provider's | layers. The customer's network is considered from the provider's | |||
perspective as the highest service layer. It interfaces to the | perspective as the highest service layer. It interfaces to the | |||
highest service layer of the service provider's network. | highest service layer of the service provider's network. | |||
Connectivity across the highest service layer of the service | Connectivity across the highest service layer of the service | |||
provider's network may be provided with support from successively | provider's network may be provided with support from successively | |||
lower service layers. Service layers are realized via a hierarchy | lower service layers. Service layers are realized via a hierarchy | |||
of network layers located generally in several regions and commonly | of network layers located generally in several regions and commonly | |||
arranged according to the switching capabilities of network devices. | arranged according to the switching capabilities of network devices. | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
For instance some customers purchase Layer 1 (i.e., transport) | For instance some customers purchase Layer 1 (i.e., transport) | |||
services from the service provider, some Layer 2 (e.g., ATM), while | services from the service provider, some Layer 2 (e.g., ATM), while | |||
others purchase Layer 3 (IP/MPLS) services. The service provider | others purchase Layer 3 (IP/MPLS) services. The service provider | |||
realizes the services by a stack of network layers located within | realizes the services by a stack of network layers located within | |||
one or more network regions. The network layers are commonly | one or more network regions. The network layers are commonly | |||
arranged according to the switching capabilities of the devices in | arranged according to the switching capabilities of the devices in | |||
the networks. Thus, a customer network may be provided on top of | the networks. Thus, a customer network may be provided on top of | |||
the GMPLS-based multi-region/multi-layer network. For example, a | the GMPLS-based multi-region/multi-layer network. For example, a | |||
Layer 1 service (realized via the network layers of TDM, and/or LSC, | Layer 1 service (realized via the network layers of TDM, and/or LSC, | |||
and/or FSC regions) may support a Layer 2 network (realized via ATM | and/or FSC regions) may support a Layer 2 network (realized via ATM | |||
skipping to change at page 8, line 32 | skipping to change at page 7, line 34 | |||
Services provided by a GMPLS-based multi-region/multi-layer network | Services provided by a GMPLS-based multi-region/multi-layer network | |||
are referred to as "Multi-region/Multi-layer network services". For | are referred to as "Multi-region/Multi-layer network services". For | |||
example, legacy IP and IP/MPLS networks can be supported on top of | example, legacy IP and IP/MPLS networks can be supported on top of | |||
multi-region/multi-layer networks. It has to be emphasized that | multi-region/multi-layer networks. It has to be emphasized that | |||
delivery of such diverse services is a strong motivator for the | delivery of such diverse services is a strong motivator for the | |||
deployment of multi-region/multi-layer networks. | deployment of multi-region/multi-layer networks. | |||
A customer network may be provided on top of a server GMPLS-based | A customer network may be provided on top of a server GMPLS-based | |||
MRN/MLN which is operated by a service provider. For example, a | MRN/MLN which is operated by a service provider. For example, a | |||
pure IP and/or an IP/MPLS network can be provided on top of GMPLS- | pure IP and/or an IP/MPLS network can be provided on top of GMPLS- | |||
based packet over optical networks [MPLS-GMPLS]. The relationship | based packet over optical networks [RFC5146]. The relationship | |||
between the networks is a client/server relationship and, such | between the networks is a client/server relationship and, such | |||
services are referred to as "MRN/MLN services". In this case, the | services are referred to as "MRN/MLN services". In this case, the | |||
customer network may form part of the MRN/MLN, or may be partially | customer network may form part of the MRN/MLN, or may be partially | |||
separated, for example to maintain separate routing information but | separated, for example to maintain separate routing information but | |||
retain common signaling. | retain common signaling. | |||
3.3. Vertical and Horizontal Interaction and Integration | 3.3. Vertical and Horizontal Interaction and Integration | |||
Vertical interaction is defined as the collaborative mechanisms | Vertical interaction is defined as the collaborative mechanisms | |||
within a network element that is capable of supporting more than | within a network element that is capable of supporting more than | |||
skipping to change at page 9, line 5 | skipping to change at page 8, line 8 | |||
layers are also a vertical interaction. Integration of these | layers are also a vertical interaction. Integration of these | |||
interactions as part of the control plane is referred to as | interactions as part of the control plane is referred to as | |||
vertical integration. Thus, this refers to the collaborative | vertical integration. Thus, this refers to the collaborative | |||
mechanisms within a single control plane instance driving multiple | mechanisms within a single control plane instance driving multiple | |||
network layers part of the same region or not. Such a concept is | network layers part of the same region or not. Such a concept is | |||
useful in order to construct a framework that facilitates efficient | useful in order to construct a framework that facilitates efficient | |||
network resource usage and rapid service provisioning in carrier | network resource usage and rapid service provisioning in carrier | |||
networks that are based on multiple layers, switching technologies, | networks that are based on multiple layers, switching technologies, | |||
or ISCs. | or ISCs. | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
Horizontal interaction is defined as the protocol exchange between | Horizontal interaction is defined as the protocol exchange between | |||
network controllers that manage transport nodes within a given | network controllers that manage transport nodes within a given | |||
layer or region. For instance, the control plane interaction | layer or region. For instance, the control plane interaction | |||
between two TDM network elements switching at OC-48 is an example | between two TDM network elements switching at OC-48 is an example | |||
of horizontal interaction. GMPLS protocol operations handle | of horizontal interaction. GMPLS protocol operations handle | |||
horizontal interactions within the same routing area. The case | horizontal interactions within the same routing area. The case | |||
where the interaction takes place across a domain boundary, such as | where the interaction takes place across a domain boundary, such as | |||
between two routing areas within the same network layer, is | between two routing areas within the same network layer, is | |||
evaluated as part of the inter- domain work [RFC4726], and is | evaluated as part of the inter- domain work [RFC4726], and is | |||
referred to as horizontal integration. Thus, horizontal integration | referred to as horizontal integration. Thus, horizontal integration | |||
skipping to change at page 10, line 5 | skipping to change at page 9, line 11 | |||
devices hosting more than one switching capability not only | devices hosting more than one switching capability not only | |||
increases the complexity of their interactions but also increases | increases the complexity of their interactions but also increases | |||
the total amount of processing individual instances would handle. | the total amount of processing individual instances would handle. | |||
- The unification of the addressing spaces helps in avoiding | - The unification of the addressing spaces helps in avoiding | |||
multiple identifiers for the same object (a link, for instance, | multiple identifiers for the same object (a link, for instance, | |||
or more generally, any network resource). On the other hand such | or more generally, any network resource). On the other hand such | |||
aggregation does not impact the separation between the control | aggregation does not impact the separation between the control | |||
plane and the data plane. | plane and the data plane. | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
- By maintaining a single routing protocol instance and a single TE | - By maintaining a single routing protocol instance and a single TE | |||
database per LSR, a unified control plane model removes the | database per LSR, a unified control plane model removes the | |||
requirement to maintain a dedicated routing topology per layer | requirement to maintain a dedicated routing topology per layer | |||
and therefore does not mandate a full mesh of routing adjacencies | and therefore does not mandate a full mesh of routing adjacencies | |||
as is the case with overlaid control planes. | as is the case with overlaid control planes. | |||
- The collaboration between technology layers where the control | - The collaboration between technology layers where the control | |||
channel is associated with the data channel (e.g. packet/framed | channel is associated with the data channel (e.g. packet/framed | |||
data planes) and technology layers where the control channel is | data planes) and technology layers where the control channel is | |||
not directly associated with the data channel (SONET/SDH, G.709, | not directly associated with the data channel (SONET/SDH, G.709, | |||
skipping to change at page 11, line 5 | skipping to change at page 10, line 7 | |||
[RFC4202]. An ISC is identified via a switching type. | [RFC4202]. An ISC is identified via a switching type. | |||
A switching type (also referred to as the switching capability | A switching type (also referred to as the switching capability | |||
type) describes the ability of a node to forward data of a | type) describes the ability of a node to forward data of a | |||
particular data plane technology, and uniquely identifies a network | particular data plane technology, and uniquely identifies a network | |||
region. The following ISC types (and, hence, regions) are defined: | region. The following ISC types (and, hence, regions) are defined: | |||
PSC, L2SC, TDM, LSC, and FSC. Each end of a data link (more | PSC, L2SC, TDM, LSC, and FSC. Each end of a data link (more | |||
precisely, each interface connecting a data link to a node) in a | precisely, each interface connecting a data link to a node) in a | |||
GMPLS network is associated with an ISC. | GMPLS network is associated with an ISC. | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
The ISC value is advertised as a part of the Interface Switching | The ISC value is advertised as a part of the Interface Switching | |||
Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end | Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end | |||
associated with a particular link interface [RFC4202]. Apart from | associated with a particular link interface [RFC4202]. Apart from | |||
the ISC, the ISCD contains information including the encoding type, | the ISC, the ISCD contains information including the encoding type, | |||
the bandwidth granularity, and the unreserved bandwidth on each of | the bandwidth granularity, and the unreserved bandwidth on each of | |||
eight priorities at which LSPs can be established. The ISCD does | eight priorities at which LSPs can be established. The ISCD does | |||
not "identify" network layers, it uniquely characterizes | not "identify" network layers, it uniquely characterizes | |||
information associated to one or more network layers. | information associated to one or more network layers. | |||
TE link end advertisements may contain multiple ISCDs. This can be | TE link end advertisements may contain multiple ISCDs. This can be | |||
skipping to change at page 12, line 4 | skipping to change at page 11, line 7 | |||
external interfaces connected to the node have both PSC and TDM | external interfaces connected to the node have both PSC and TDM | |||
capabilities. | capabilities. | |||
Additionally, TE link advertisements issued by a simplex or a | Additionally, TE link advertisements issued by a simplex or a | |||
hybrid node may need to provide information about the node's | hybrid node may need to provide information about the node's | |||
internal adjustment capacity between the switching technologies | internal adjustment capacity between the switching technologies | |||
supported. The term "adjustment" capacity refers to the property of | supported. The term "adjustment" capacity refers to the property of | |||
an hybrid node to interconnect different switching capabilities it | an hybrid node to interconnect different switching capabilities it | |||
provides through its external interfaces.. This information allows | provides through its external interfaces.. This information allows | |||
path computation to select an end- to-end multi-layer or multi- | path computation to select an end- to-end multi-layer or multi- | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
region path that includes links of different switching capabilities | region path that includes links of different switching capabilities | |||
that are joined by LSRs that can adapt the signal between the links. | that are joined by LSRs that can adapt the signal between the links. | |||
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes | 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes | |||
This type of network contains at least one hybrid node, zero or | This type of network contains at least one hybrid node, zero or | |||
more simplex nodes, and a set of single-switching-type-capable | more simplex nodes, and a set of single-switching-type-capable | |||
nodes. | nodes. | |||
Figure 1 shows an example hybrid node. The hybrid node has two | Figure 1 shows an example hybrid node. The hybrid node has two | |||
switching elements (matrices), which support, for instance, TDM and | switching elements (matrices), which support, for instance, TDM and | |||
PSC switching respectively. The node terminates a PSC and a TDM | PSC switching respectively. The node terminates a PSC and a TDM | |||
link (Link1 and Link2 respectively). It also has an internal link | link (Link1 and Link2 respectively). It also has an internal link | |||
connecting the two switching elements. | connecting the two switching elements. | |||
skipping to change at page 12, line 30 | skipping to change at page 11, line 32 | |||
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, say, | way that it is possible to terminate some of the resources of, say, | |||
Link2 and provide adjustment for PSC traffic received/sent over the | Link2 and provide adjustment for PSC traffic received/sent over the | |||
PSC interface (#b). This situation is modeled in GMPLS by | PSC interface (#b). This situation is modeled in GMPLS by | |||
connecting the local end of Link2 to the TDM switching element via | connecting the local end of Link2 to the TDM switching element via | |||
an additional interface realizing the termination/adjustment | an additional interface realizing the termination/adjustment | |||
function. There are two possible ways to set up PSC LSPs through | function. There are two possible ways to set up PSC LSPs through | |||
the hybrid node. Available resource advertisement (i.e., Unreserved | the hybrid node. Available resource advertisement (i.e., Unreserved | |||
and Min/Max LSP Bandwidth) should cover both of these methods. | and Min/Max LSP Bandwidth) should cover both of these methods. | |||
Network element | ||||
............................. | ............................. | |||
: Network element : | ||||
: -------- : | : -------- : | |||
: | PSC | : | : | PSC | : | |||
Link1 -------------<->--|#a | : | Link1 -------------<->--|#a | : | |||
: | | : | : | | : | |||
: +--<->---|#b | : | : +--<->---|#b | : | |||
: | -------- : | : | -------- : | |||
: | ---------- : | : | ---------- : | |||
TDM : +--<->--|#c TDM | : | TDM : +--<->--|#c TDM | : | |||
+PSC : | | : | +PSC : | | : | |||
Link2 ------------<->--|#d | : | Link2 ------------<->--|#d | : | |||
skipping to change at page 13, line 4 | skipping to change at page 12, line 7 | |||
Figure 1. Hybrid node. | Figure 1. Hybrid node. | |||
4.3. Integrated Traffic Engineering (TE) and Resource Control | 4.3. Integrated Traffic Engineering (TE) and Resource Control | |||
In GMPLS-based multi-region/multi-layer networks, TE Links may be | In GMPLS-based multi-region/multi-layer networks, TE Links may be | |||
consolidated into a single Traffic Engineering Database (TED) for | consolidated into a single Traffic Engineering Database (TED) for | |||
use by the single control plane instance. Since this TED contains | use by the single control plane instance. Since this TED contains | |||
the information relative to all the layers of all regions in the | the information relative to all the layers of all regions in the | |||
network, a path across multiple layers (possibly crossing multiple | network, a path across multiple layers (possibly crossing multiple | |||
regions) can be computed using the information in this TED. Thus, | regions) can be computed using the information in this TED. Thus, | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
optimization of network resources across the multiple layers of the | optimization of network resources across the multiple layers of the | |||
same region and across multiple regions can be achieved. | same region and across multiple regions can be achieved. | |||
These concepts allow for the operation of one network layer over | These concepts allow for the operation of one network layer over | |||
the topology (that is, TE links) provided by other network layers | the topology (that is, TE links) provided by other network layers | |||
(for example, the use of a lower layer LSC LSP carrying PSC LSPs). | (for example, the use of a lower layer LSC LSP carrying PSC LSPs). | |||
In turn, a greater degree of control and inter-working can be | In turn, a greater degree of control and inter-working can be | |||
achieved, including (but not limited too): | achieved, including (but not limited too): | |||
- Dynamic establishment of Forwarding Adjacency (FA) LSPs | - Dynamic establishment of Forwarding Adjacency (FA) LSPs | |||
skipping to change at page 13, line 50 | skipping to change at page 12, line 51 | |||
layer. From a signaling perspective, there are two alternatives to | layer. From a signaling perspective, there are two alternatives to | |||
establish the lower layer FA-LSP: static (pre-provisioned) and | establish the lower layer FA-LSP: static (pre-provisioned) and | |||
dynamic (triggered). A pre-provisioned FA-LSP may be initiated | dynamic (triggered). A pre-provisioned FA-LSP may be initiated | |||
either by the operator or automatically using features like TE | either by the operator or automatically using features like TE | |||
auto-mesh [RFC4972]. If such a lower layer LSP does not already | auto-mesh [RFC4972]. If such a lower layer LSP does not already | |||
exist, the LSP may be established dynamically. Such a mechanism is | exist, the LSP may be established dynamically. Such a mechanism is | |||
referred to as "triggered signaling". | referred to as "triggered signaling". | |||
4.3.2. FA-LSPs | 4.3.2. FA-LSPs | |||
Once an LSP is created across a layer from one layer border node | Once an LSP is created across a layer from one layer border node to | |||
to another, it can be used as a data link in an upper layer. | another, it can be used as a data link in an upper layer. | |||
Furthermore, it can be advertised as a TE-link, allowing other | Furthermore, it can be advertised as a TE-link, allowing other | |||
nodes to consider the LSP as a TE link for their path computation | nodes to consider the LSP as a TE link for their path computation | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
[RFC4206]. An LSP created either statically or dynamically by one | [RFC4206]. An LSP created either statically or dynamically by one | |||
instance of the control plane and advertised as a TE link into the | instance of the control plane and advertised as a TE link into the | |||
same instance of the control plane is called a Forwarding Adjacency | same instance of the control plane is called a Forwarding Adjacency | |||
LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE | LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE | |||
link is called a Forwarding Adjacency (FA). An FA has the special | link is called a Forwarding Adjacency (FA). An FA has the special | |||
characteristic of not requiring a routing adjacency (peering) | characteristic of not requiring a routing adjacency (peering) | |||
between its end points yet still guaranteeing control plane | between its end points yet still guaranteeing control plane | |||
connectivity between the FA-LSP end points based on a signaling | connectivity between the FA-LSP end points based on a signaling | |||
adjacency. An FA is a useful and powerful tool for improving the | adjacency. An FA is a useful and powerful tool for improving the | |||
scalability of GMPLS Traffic Engineering (TE) capable networks | scalability of GMPLS Traffic Engineering (TE) capable networks | |||
skipping to change at page 15, line 5 | skipping to change at page 14, line 5 | |||
words, provides a virtual network topology (VNT) to the upper- | words, provides a virtual network topology (VNT) to the upper- | |||
layers. For instance, a set of LSPs, each of which is supported by | layers. For instance, a set of LSPs, each of which is supported by | |||
an LSC LSP, provides a virtual network topology to the layers of a | an LSC LSP, provides a virtual network topology to the layers of a | |||
PSC region, assuming that the PSC region is connected to the LSC | PSC region, assuming that the PSC region is connected to the LSC | |||
region. Note that a single lower-layer LSP is a special case of the | region. Note that a single lower-layer LSP is a special case of the | |||
VNT. The virtual network topology is configured by setting up or | VNT. The virtual network topology is configured by setting up or | |||
tearing down the lower layer LSPs. By using GMPLS signaling and | tearing down the lower layer LSPs. By using GMPLS signaling and | |||
routing protocols, the virtual network topology can be adapted to | routing protocols, the virtual network topology can be adapted to | |||
traffic demands. | traffic demands. | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
A lower-layer LSP appears as a TE-link in the VNT. Whether the | A lower-layer LSP appears as a TE-link in the VNT. Whether the | |||
diversely-routed lower-layer LSPs are used or not, the routes of | diversely-routed lower-layer LSPs are used or not, the routes of | |||
lower-layer LSPs are hidden from the upper layer in the VNT. Thus, | lower-layer LSPs are hidden from the upper layer in the VNT. Thus, | |||
the VNT simplifies the upper-layer routing and traffic engineering | the VNT simplifies the upper-layer routing and traffic engineering | |||
decisions by hiding the routes taken by the lower-layer LSPs. | decisions by hiding the routes taken by the lower-layer LSPs. | |||
However, hiding the routes of the lower-layer LSPs may lose | However, hiding the routes of the lower-layer LSPs may lose | |||
important information that is needed to make the higher-layer LSPs | important information that is needed to make the higher-layer LSPs | |||
reliable. For instance, the routing and traffic engineering in the | reliable. For instance, the routing and traffic engineering in the | |||
IP/MPLS layer does not usually consider how the IP/MPLS TE links | IP/MPLS layer does not usually consider how the IP/MPLS TE links | |||
are formed from optical paths that are routed in the fiber layer. | are formed from optical paths that are routed in the fiber layer. | |||
skipping to change at page 15, line 42 | skipping to change at page 14, line 40 | |||
performed by computing the new VNT from the traffic demand matrix | performed by computing the new VNT from the traffic demand matrix | |||
and optionally from the current VNT. Exact details are outside the | and optionally from the current VNT. Exact details are outside the | |||
scope of this document. However, this method may be tailored | scope of this document. However, this method may be tailored | |||
according to the service provider's policy regarding network | according to the service provider's policy regarding network | |||
performance and quality of service (delay, loss/disruption, | performance and quality of service (delay, loss/disruption, | |||
utilization, residual capacity, reliability). | utilization, residual capacity, reliability). | |||
5. Requirements | 5. Requirements | |||
5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes | 5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes | |||
The MRN/MLN can consist of single-switching-type-capable and | ||||
multi- switching-type-capable nodes. The path computation mechanism | The MRN/MLN can consist of single-switching-type-capable and multi- | |||
in the MLN SHOULD be able to compute paths consisting of any | switching-type-capable nodes. The path computation mechanism in the | |||
combination of such nodes. | MLN should be able to compute paths consisting of any combination | |||
of such nodes. | ||||
Both single-switching-type-capable and multi-switching-type-capable | Both single-switching-type-capable and multi-switching-type-capable | |||
(simplex or hybrid) nodes could play the role of layer boundary. | (simplex or hybrid) nodes could play the role of layer boundary. | |||
MRN/MLN Path computation SHOULD handle TE topologies built of any | MRN/MLN Path computation should handle TE topologies built of any | |||
combination of nodes. | combination of nodes. | |||
5.2. Advertisement of the Available Adjustment Resource | 5.2. Advertisement of the Available Adjustment Resource | |||
A hybrid node SHOULD maintain resources on its internal links (the | A hybrid node should maintain resources on its internal links (the | |||
links required for vertical (layer) integration) and SHOULD | links required for vertical (layer) integration). Likewise, path | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | computation elements should be prepared to use the availability of | |||
advertise the resource information for those links. Likewise, path | ||||
computation elements SHOULD be prepared to use the availability of | ||||
termination/ adjustment resources as a constraint in MRN/MLN path | termination/ adjustment resources as a constraint in MRN/MLN path | |||
computations to reduce the higher layer LSP setup blocking | computations to reduce the higher layer LSP setup blocking | |||
probability caused by the lack of necessary termination/adjustment | probability caused by the lack of necessary termination/adjustment | |||
resources in the lower layer(s). | resources in the lower layer(s). | |||
The advertisement of the adjustment capability to terminate LSPs of | The advertisement of the adjustment capability to terminate LSPs of | |||
lower-region and forward traffic in the upper-region is REQUIRED, | lower-region and forward traffic in the upper-region is REQUIRED, | |||
as it provides critical information when performing multi-region | as it provides critical information when performing multi-region | |||
path computation. | path computation. | |||
The mechanism SHOULD cover the case where the upper-layer links | The path computation mechanism should cover the case where the | |||
which are directly connected to upper-layer switching element and | upper-layer links which are directly connected to upper-layer | |||
the ones which are connected through internal links between upper- | switching element and the ones which are connected through internal | |||
layer element and lower-layer element coexist (see Section 4.2.1). | links between upper-layer element and lower-layer element coexist | |||
(see Section 4.2.1). | ||||
5.3. Scalability | 5.3. Scalability | |||
The MRN/MLN relies on unified routing and traffic engineering | The MRN/MLN relies on unified routing and traffic engineering | |||
models. | models. | |||
- Unified routing model: By maintaining a single routing protocol | - Unified routing model: By maintaining a single routing protocol | |||
instance and a single TE database per LSR, a unified control | instance and a single TE database per LSR, a unified control | |||
plane model removes the requirement to maintain a dedicated | plane model removes the requirement to maintain a dedicated | |||
routing topology per layer, and therefore does not mandate a | routing topology per layer, and therefore does not mandate a full | |||
full mesh of routing adjacencies per layer. | mesh of routing adjacencies per layer. | |||
- Unified TE model: The TED in each LSR is populated with TE-links | - Unified TE model: The TED in each LSR is populated with TE-links | |||
from all layers of all regions (TE link interfaces on multiple- | from all layers of all regions (TE link interfaces on multiple- | |||
switching-capability LSRs can be advertised with multiple ISCDs). | switching-capability LSRs can be advertised with multiple ISCDs). | |||
This may lead to an increase in the amount of information that | This may lead to an increase in the amount of information that | |||
has to be flooded and stored within the network. | has to be flooded and stored within the network. | |||
Furthermore, path computation times, which may be of great | Furthermore, path computation times, which may be of great | |||
importance during restoration, will depend on the size of the TED. | importance during restoration, will depend on the size of the TED. | |||
skipping to change at page 17, line 5 | skipping to change at page 16, line 5 | |||
- Number of nodes | - Number of nodes | |||
- Number of TE-links (including FA-LSPs) | - Number of TE-links (including FA-LSPs) | |||
- Number of LSPs - Number of regions and layers | - Number of LSPs - Number of regions and layers | |||
- Number of ISCDs per TE-link. | - Number of ISCDs per TE-link. | |||
Further, design of the routing protocols MUST NOT prevent TE | Further, design of the routing protocols MUST NOT prevent TE | |||
information filtering based on ISCDs. The path computation | information filtering based on ISCDs. The path computation | |||
mechanism and the signaling protocol SHOULD be able to operate on | mechanism and the signaling protocol SHOULD be able to operate on | |||
partial TE information. | partial TE information. | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
Since TE Links can advertise multiple Interface Switching | Since TE Links can advertise multiple Interface Switching | |||
Capabilities (ISCs), the number of links can be limited (by | Capabilities (ISCs), the number of links can be limited (by | |||
combination) by using specific topological maps referred to as VNTs | combination) by using specific topological maps referred to as VNTs | |||
(Virtual Network Topologies). The introduction of virtual | (Virtual Network Topologies). The introduction of virtual | |||
topological maps leads us to consider the concept of emulation of | topological maps leads us to consider the concept of emulation of | |||
data plane overlays. | data plane overlays. | |||
5.4. Stability | 5.4. Stability | |||
Path computation is dependent on the network topology and | Path computation is dependent on the network topology and | |||
associated link state. The path computation stability of an upper | associated link state. The path computation stability of an upper | |||
layer may be impaired if the VNT changes frequently and/or if the | layer may be impaired if the VNT changes frequently and/or if the | |||
status and TE parameters (the TE metric, for instance) of links in | status and TE parameters (the TE metric, for instance) of links in | |||
the VNT changes frequently. In this context, robustness of the VNT | the VNT changes frequently. In this context, robustness of the VNT | |||
is defined as the capability to smooth changes that may occur and | is defined as the capability to smooth changes that may occur and | |||
avoid their propagation into higher layers. Changes to the VNT may | avoid their propagation into higher layers. Changes to the VNT may | |||
be caused by the creation, deletion, or modification of LSPs. | be caused by the creation, deletion, or modification of LSPs. | |||
Creation, deletion, and modification of LSPs MAY be triggered by | Protocol mechanisms MUST be provided to enable creation, deletion, | |||
adjacent layers or through operational actions to meet traffic | and modification of LSPs triggered through operational actions. | |||
demand changes, topology changes, signaling requests from the upper | Protocol mechanisms SHOULD be provided to enable similar functions | |||
layer, and network failures. Routing robustness SHOULD be traded | triggered by adjacent layers. Protocol mechanisms MAY be provided | |||
with adaptability with respect to the change of incoming traffic | to enable similar functions to adapt to the environment changes | |||
requests. | such as traffic demand changes, topology changes, and network | |||
failures. Routing robustness should be traded with adaptability of | ||||
those changes. | ||||
5.5. Disruption Minimization | 5.5. Disruption Minimization | |||
When reconfiguring the VNT according to a change in traffic demand, | When reconfiguring the VNT according to a change in traffic demand, | |||
the upper-layer LSP might be disrupted. Such disruption to the | the upper-layer LSP might be disrupted. Such disruption to the | |||
upper layers MUST be minimized. | upper layers must be minimized. | |||
When residual resource decreases to a certain level, some lower | When residual resource decreases to a certain level, some lower | |||
layer LSPs MAY be released according to local or network policies. | layer LSPs may be released according to local or network policies. | |||
There is a trade-off between minimizing the amount of resource | There is a trade-off between minimizing the amount of resource | |||
reserved in the lower layer and disrupting higher layer traffic | reserved in the lower layer and disrupting higher layer traffic | |||
(i.e. moving the traffic to other TE-LSPs so that some LSPs can be | (i.e. moving the traffic to other TE-LSPs so that some LSPs can be | |||
released). Such traffic disruption MAY be allowed, but MUST be | released). Such traffic disruption may be allowed, but MUST be | |||
under the control of policy that can be configured by the operator. | under the control of policy that can be configured by the operator. | |||
Any repositioning of traffic MUST be as non-disruptive as possible | Any repositioning of traffic MUST be as non-disruptive as possible | |||
(for example, using make-before-break). | (for example, using make-before-break). | |||
5.6. LSP Attribute Inheritance | 5.6. LSP Attribute Inheritance | |||
TE-Link parameters SHOULD be inherited from the parameters of the | TE-Link parameters should be inherited from the parameters of the | |||
LSP that provides the TE-link, and so from the TE-links in the | LSP that provides the TE-link, and so from the TE-links in the | |||
lower layer that are traversed by the LSP. | lower layer that are traversed by the LSP. | |||
These include: | These include: | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
- Interface Switching Capability | - Interface Switching Capability | |||
- TE metric | - TE metric | |||
- Maximum LSP bandwidth per priority level | - Maximum LSP bandwidth per priority level | |||
- Unreserved bandwidth for all priority levels | - Unreserved bandwidth for all priority levels | |||
- Maximum Reservable bandwidth | - Maximum Reservable bandwidth | |||
- Protection attribute | - Protection attribute | |||
- Minimum LSP bandwidth (depending on the Switching Capability) | - Minimum LSP bandwidth (depending on the Switching Capability) | |||
- SRLG | - SRLG | |||
Inheritance rules MUST be applied based on specific policies. | Inheritance rules must be applied based on specific policies. | |||
Particular attention should be given to the inheritance of TE | Particular attention should be given to the inheritance of TE | |||
metric (which may be other than a strict sum of the metrics of the | metric (which may be other than a strict sum of the metrics of the | |||
component TE links at the lower layer), protection attributes, and | component TE links at the lower layer), protection attributes, and | |||
SRLG. | SRLG. | |||
As described earlier, hiding the routes of the lower-layer LSPs may | As described earlier, hiding the routes of the lower-layer LSPs may | |||
lose important information necessary to make LSPs in the higher | lose important information necessary to make LSPs in the higher | |||
layer network reliable. SRLGs may be used to identify which lower- | layer network reliable. SRLGs may be used to identify which lower- | |||
layer LSPs share the same failure risk so that the potential risk | layer LSPs share the same failure risk so that the potential risk | |||
of the VNT becoming disjoint can be minimized, and so that resource | of the VNT becoming disjoint can be minimized, and so that resource | |||
disjoint protection paths can be set up in the higher layer. How to | disjoint protection paths can be set up in the higher layer. How to | |||
inherit the SRLG information from the lower layer to the upper | inherit the SRLG information from the lower layer to the upper | |||
layer needs more discussion and is out of scope of this document. | layer needs more discussion and is out of scope of this document. | |||
5.7. Computing Paths With and Without Nested Signaling | 5.7. Computing Paths With and Without Nested Signaling | |||
Path computation MAY take into account LSP region and layer | Path computation can take into account LSP region and layer | |||
boundaries when computing a path for an LSP. For example, path | boundaries when computing a path for an LSP. Path computation may | |||
computation MAY restrict the path taken by an LSP to only the links | restrict the path taken by an LSP to only the links whose interface | |||
whose interface switching capability is PSC. | switching capability is PSC. For example, suppose that a TDM-LSP is | |||
routed over the topology composed of TE links of the same TDM layer. | ||||
Interface switching capability is used as a constraint in path | In calculating the path for the LSP, the TED may be filtered to | |||
computation. For example, a TDM-LSP is routed over the topology | include only links where both end include requested LSP switching | |||
composed of TE links of the same TDM layer. In calculating the path | type. In this way hierarchical routing is done by using a TED | |||
for the LSP, the TED MAY be filtered to include only links where | filtered with respect to switching capability (that is, with | |||
both end include requested LSP switching type. In this way | respect to particular layer). | |||
hierarchical routing is done by using a TED filtered with respect | ||||
to switching capability (that is, with respect to particular layer). | ||||
If triggered signaling is allowed, the path computation mechanism | If triggered signaling is allowed, the path computation mechanism | |||
MAY produce a route containing multiple layers/regions. The path is | may produce a route containing multiple layers/regions. The path is | |||
computed over the multiple layers/regions even if the path is not | computed over the multiple layers/regions even if the path is not | |||
"connected" in the same layer as the endpoints of the path exist. | "connected" in the same layer as the endpoints of the path exist. | |||
Note that here we assume that triggered signaling will be invoked | Note that here we assume that triggered signaling will be invoked | |||
to make the path "connected", when the upper-layer signaling | to make the path "connected", when the upper-layer signaling | |||
request arrives at the boundary node. | request arrives at the boundary node. | |||
The upper-layer signaling request may contain an ERO that includes | The upper-layer signaling request MAY contain an ERO (Explicit | |||
only hops in the upper layer, in which case the boundary node is | Route Object) that includes only hops in the upper layer, in which | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | case the boundary node is responsible for triggered creation of the | |||
lower-layer FA-LSP using a path of its choice, or for the selection | ||||
responsible for triggered creation of the lower-layer FA-LSP using | of any available lower layer LSP as a data link for the higher | |||
a path of its choice, or for the selection of any available lower | layer. This mechanism is appropriate for environments where the TED | |||
layer LSP as a data link for the higher layer. This mechanism is | is filtered in the higher layer, where separate routing instances | |||
appropriate for environments where the TED is filtered in the | are used per layer, or where administrative policies prevent the | |||
higher layer, where separate routing instances are used per layer, | higher layer from specifying paths through the lower layer. | |||
or where administrative policies prevent the higher layer from | ||||
specifying paths through the lower layer. | ||||
Obviously, if the lower layer LSP has been advertised as a TE link | Obviously, if the lower layer LSP has been advertised as a TE link | |||
(virtual or real) into the higher layer, then the higher layer | (virtual or real) into the higher layer, then the higher layer | |||
signaling request may contain the TE link identifier and so | signaling request MAY contain the TE link identifier and so | |||
indicate the lower layer resources to be used. But in this case, | indicate the lower layer resources to be used. But in this case, | |||
the path of the lower layer LSP can be dynamically changed by the | the path of the lower layer LSP can be dynamically changed by the | |||
lower layer at any time. | lower layer at any time. | |||
Alternatively, the upper-layer signaling request may contain an ERO | Alternatively, the upper-layer signaling request MAY contain an ERO | |||
specifying the lower layer FA-LSP route. In this case, the boundary | specifying the lower layer FA-LSP route. In this case, the boundary | |||
node is responsible for decision as to which it should use the path | node MAY decide whether it should use the path contained in the | |||
contained in the strict ERO or it should re-compute the path within | strict ERO or re-compute the path within the lower-layer. | |||
in the lower-layer. | ||||
Even in case the lower-layer FA-LSPs are already established, a | Even in the case that the lower-layer FA-LSPs are already | |||
signaling request may also be encoded as loose ERO. In this | established, a signaling request may also be encoded as a loose ERO. | |||
situation, it is up to the boundary node to decide whether it | In this situation, it is up to the boundary node to decide whether | |||
should a new lower-layer FA-LSP or it should use the existing | it should create a new lower-layer FA-LSP or it should use an | |||
lower-layer FA-LSPs. | existing lower-layer FA-LSPs. | |||
The lower-layer FA-LSP can be advertised just as an FA-LSP in the | The lower-layer FA-LSP can be advertised just as an FA-LSP in the | |||
upper-layer or an IGP adjacency can be brought up on the lower- | upper-layer or an IGP adjacency can be brought up on the lower- | |||
layer FA-LSP. | layer FA-LSP. | |||
5.8. LSP Resource Utilization | 5.8. LSP Resource Utilization | |||
It MUST be possible to utilize network resources efficiently. | Resource usage in all layers should be optimized as a whole (i.e., | |||
Particularly, resource usage in all layers SHOULD be optimized as a | across all layers), in a coordinated manner, (i.e., taking all | |||
whole (i.e., across all layers), in a coordinated manner, (i.e., | layers into account). The number of lower-layer LSPs carrying | |||
taking all layers into account). The number of lower-layer LSPs | upper-layer LSPs should be minimized (note that multiple LSPs may | |||
carrying upper-layer LSPs SHOULD be minimized (note that multiple | be used for load balancing). Lower-layer LSPs that could have their | |||
LSPs MAY be used for load balancing). Lower-layer LSPs that could | traffic re-routed onto other LSPs are unnecessary and should be | |||
have their traffic re-routed onto other LSPs are unnecessary and | avoided. | |||
SHOULD be avoided. | ||||
5.8.1. FA-LSP Release and Setup | 5.8.1. FA-LSP Release and Setup | |||
Statistical multiplexing can only be employed in PSC and L2SC | ||||
regions. A PSC or L2SC LSP may or may not consume the maximum | ||||
reservable bandwidth of the TE link (FA-LSP) that carries it. On | ||||
the other hand, a TDM, or LSC LSP always consumes a fixed amount of | ||||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
bandwidth as long as it exists (and is fully instantiated) because | ||||
statistical multiplexing is not available. | ||||
If there is low traffic demand, some FA-LSPs that do not carry any | If there is low traffic demand, some FA-LSPs that do not carry any | |||
higher-layer LSP MAY be released so that lower-layer resources are | higher-layer LSP may be released so that lower-layer resources are | |||
released and can be assigned to other uses. Note that if a small | released and can be assigned to other uses. Note that if a small | |||
fraction of the available bandwidth of an FA-LSP is still in use, | fraction of the available bandwidth of an FA-LSP is still in use, | |||
the nested LSPs can also be re-routed to other FA-LSPs (optionally | the nested LSPs can also be re-routed to other FA-LSPs (optionally | |||
using the make-before-break technique) to completely free up the | using the make-before-break technique) to completely free up the | |||
FA-LSP. Alternatively, unused FA-LSPs MAY be retained for future | FA-LSP. Alternatively, unused FA-LSPs may be retained for future | |||
use. Release or retention of underutilized FA-LSPs is a policy | use. Release or retention of underutilized FA-LSPs is a policy | |||
decision. | decision. | |||
As part of the re-optimization process, the solution MUST allow | As part of the re-optimization process, the solution MUST allow | |||
rerouting of an FA-LSP while keeping interface identifiers of | rerouting of an FA-LSP while keeping interface identifiers of | |||
corresponding TE links unchanged. Further, this process MUST be | corresponding TE links unchanged. Further, this process MUST be | |||
possible while the FA-LSP is carrying traffic (higher layer LSPs) | possible while the FA-LSP is carrying traffic (higher layer LSPs) | |||
with minimal disruption to the traffic. | with minimal disruption to the traffic. | |||
Additional FA-LSPs MAY also be created based on policy, which might | Additional FA-LSPs may also be created based on policy, which might | |||
consider residual resources and the change of traffic demand across | consider residual resources and the change of traffic demand across | |||
the region. By creating the new FA-LSPs, the network performance | the region. By creating the new FA-LSPs, the network performance | |||
such as maximum residual capacity may increase. | such as maximum residual capacity may increase. | |||
As the number of FA-LSPs grows, the residual resource may decrease. | As the number of FA-LSPs grows, the residual resource may decrease. | |||
In this case, re-optimization of FA-LSPs MAY be invoked according | In this case, re-optimization of FA-LSPs may be invoked according | |||
to policy. | to policy. | |||
Any solution MUST include measures to protect against network | Any solution MUST include measures to protect against network | |||
destabilization caused by the rapid setup and teardown of LSPs as | destabilization caused by the rapid setup and teardown of LSPs as | |||
traffic demand varies near a threshold. | traffic demand varies near a threshold. | |||
Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly | Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly | |||
advertise the LSP as a TE link and to coordinate into which routing | advertise the LSP as a TE link and to coordinate into which routing | |||
instances the TE link should be advertised. | instances the TE link should be advertised. | |||
5.8.2. Virtual TE-Links | 5.8.2. Virtual TE-Links | |||
It may be considered disadvantageous to fully instantiate (i.e. | It may be considered disadvantageous to fully instantiate (i.e. | |||
pre- provision) the set of lower layer LSPs that provide the VNT | pre- provision) the set of lower layer LSPs that provide the VNT | |||
since this might reserve bandwidth that could be used for other | since this might reserve bandwidth that could be used for other | |||
LSPs in the absence of upper-layer traffic. | LSPs in the absence of upper-layer traffic. | |||
skipping to change at page 20, line 49 | skipping to change at page 19, line 36 | |||
instances the TE link should be advertised. | instances the TE link should be advertised. | |||
5.8.2. Virtual TE-Links | 5.8.2. Virtual TE-Links | |||
It may be considered disadvantageous to fully instantiate (i.e. | It may be considered disadvantageous to fully instantiate (i.e. | |||
pre- provision) the set of lower layer LSPs that provide the VNT | pre- provision) the set of lower layer LSPs that provide the VNT | |||
since this might reserve bandwidth that could be used for other | since this might reserve bandwidth that could be used for other | |||
LSPs in the absence of upper-layer traffic. | LSPs in the absence of upper-layer traffic. | |||
However, in order to allow path computation of upper-layer LSPs | However, in order to allow path computation of upper-layer LSPs | |||
across the lower-layer, the lower-layer LSPs MAY be advertised into | across the lower-layer, the lower-layer LSPs may be advertised into | |||
the upper-layer as though they had been fully established, but | the upper-layer as though they had been fully established, but | |||
without actually establishing them. Such TE links that represent | without actually establishing them. Such TE links that represent | |||
the possibility of an underlying LSP are termed "virtual TE-links." | the possibility of an underlying LSP are termed "virtual TE-links." | |||
It is an implementation choice at a layer boundary node whether to | It is an implementation choice at a layer boundary node whether to | |||
create real or virtual TE-links, and the choice if available in an | create real or virtual TE-links, and the choice if available in an | |||
implementation MUST be under the control of operator policy. Note | implementation MUST be under the control of operator policy. Note | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
that there is no requirement to support the creation of virtual TE- | that there is no requirement to support the creation of virtual TE- | |||
links, since real TE-links (with established LSPs) may be used, and | links, since real TE-links (with established LSPs) may be used, and | |||
even if there are no TE-links (virtual or real) advertised to the | even if there are no TE-links (virtual or real) advertised to the | |||
higher layer, it is possible to route a higher layer LSP into a | higher layer, it is possible to route a higher layer LSP into a | |||
lower layer on the assumptions that proper hierarchical LSPs in the | lower layer on the assumptions that proper hierarchical LSPs in the | |||
lower layer will be dynamically created (triggered) as needed. | lower layer will be dynamically created (triggered) as needed. | |||
If an upper-layer LSP that makes use of a virtual TE-Link is set up, | If an upper-layer LSP that makes use of a virtual TE-Link is set up, | |||
the underlying LSP MUST be immediately signaled in the lower layer. | the underlying LSP MUST be immediately signaled in the lower layer. | |||
If virtual TE-Links are used in place of pre-established LSPs, the | If virtual TE-Links are used in place of pre-established LSPs, the | |||
TE-links across the upper-layer can remain stable using pre- | TE-links across the upper-layer can remain stable using pre- | |||
computed paths while wastage of bandwidth within the lower-layer | computed paths while wastage of bandwidth within the lower-layer | |||
and unnecessary reservation of adaptation resource at the border | and unnecessary reservation of adaptation resource at the border | |||
nodes can be avoided. | nodes can be avoided. | |||
The solution SHOULD provide operations to facilitate the build-up | The solution SHOULD provide operations to facilitate the build-up | |||
of such virtual TE-links, taking into account the (forecast) | of such virtual TE-links, taking into account the (forecast) | |||
traffic demand and available resource in the lower-layer. | traffic demand and available resource in the lower-layer. | |||
Virtual TE-links MAY be added, removed or modified dynamically (by | Virtual TE-links can be added, removed or modified dynamically (by | |||
changing their capacity) according to the change of the (forecast) | changing their capacity) according to the change of the (forecast) | |||
traffic demand and the available resource in the lower-layer. The | traffic demand and the available resource in the lower-layer. It | |||
maximum number of virtual TE links that can be defined SHOULD be | MUST be possible to add, remove, and modify virtual TE-links in a | |||
configurable. | dynamic way. | |||
Any solution MUST include measures to protect against network | Any solution MUST include measures to protect against network | |||
destabilization caused by the rapid changes in the virtual network | destabilization caused by the rapid changes in the virtual network | |||
topology as traffic demand varies near a threshold. | topology as traffic demand varies near a threshold. | |||
The concept of the VNT can be extended to allow the virtual TE- | The concept of the VNT can be extended to allow the virtual TE- | |||
links to form part of the VNT. The combination of the fully | links to form part of the VNT. The combination of the fully | |||
provisioned TE- links and the virtual TE-links defines the VNT | provisioned TE- links and the virtual TE-links defines the VNT | |||
provided by the lower layer. The VNT can be changed by setting up | provided by the lower layer. The VNT can be changed by setting up | |||
and/or tearing down virtual TE links as well as by modifying real | and/or tearing down virtual TE links as well as by modifying real | |||
skipping to change at page 21, line 54 | skipping to change at page 20, line 40 | |||
In some situations, selective advertisement of the preferred | In some situations, selective advertisement of the preferred | |||
connectivity among a set of border nodes between layers may be | connectivity among a set of border nodes between layers may be | |||
appropriate. Further decreasing the number of advertisement of the | appropriate. Further decreasing the number of advertisement of the | |||
virtual connectivity can be achieved by abstracting the topology | virtual connectivity can be achieved by abstracting the topology | |||
(between border nodes) using models similar to those detailed in | (between border nodes) using models similar to those detailed in | |||
[RFC4847]. | [RFC4847]. | |||
5.9. Verification of the LSPs | 5.9. Verification of the LSPs | |||
When a lower layer LSP is established for use as a data link by a | When a lower layer LSP is established for use as a data link by a | |||
higher layer, the LSP MAY be verified for correct connectivity and | higher layer, the LSP may be verified for correct connectivity and | |||
data integrity. Such mechanisms are data technology-specific and | data integrity before it is made available for use. Such mechanisms | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | are data technology-specific and are beyond the scope of this | |||
document, but the GMPLS protocols SHOULD provide mechanisms for the | ||||
coordination of data link verification. | ||||
are beyond the scope of this document, but may be coordinated | 5.10. Management | |||
through the GMPLS control plane. | ||||
MIB modules exist for the modeling and management of GMPLS networks | ||||
[RFC4802], [RFC4803]. Some deployments of GMPLS networks may choose | ||||
to use MIB modules to operate individual network layers. In these | ||||
cases, operators may desire to coordinate layers through a further | ||||
MIB module. Multi-layer protocol solutions SHOULD be manageable | ||||
through MIB modules. A further MIB module to coordinate multiple | ||||
network layers may be produced. | ||||
OAM tools are important to the successful deployment of networks. | ||||
Protocol solutions for individual network layers SHOULD include | ||||
mechanisms for OAM or to make use of OAM features inherent in the | ||||
physical media of the layers. Multi-layer protocol solutions SHOULD | ||||
provide mechanisms to coordinate OAM mechanisms operating in each | ||||
layer. | ||||
6. Security Considerations | 6. Security Considerations | |||
The MLN/MRN architecture does not introduce any new security | The MLN/MRN architecture does not introduce any new security | |||
requirements over the general GMPLS architecture described in | requirements over the general GMPLS architecture described in | |||
[RFC3945]. Additional security considerations form MPLS and GMPLS | [RFC3945]. Additional security considerations form MPLS and GMPLS | |||
networks are described in [MPLS-SEC]. | networks are described in [MPLS-SEC]. | |||
However, where the separate layers of a MLN/MRN network are | However, where the separate layers of a MLN/MRN network are | |||
operated as different administrative domains, additional security | operated as different administrative domains, additional security | |||
skipping to change at page 22, line 35 | skipping to change at page 21, line 40 | |||
It is expected that solution documents will include a full analysis | It is expected that solution documents will include a full analysis | |||
of the security issues that any protocol extensions introduce. | of the security issues that any protocol extensions introduce. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This informational document makes no requests to IANA for action. | This informational document makes no requests to IANA for action. | |||
8. Acknowledgements | 8. Acknowledgements | |||
The authors would like to thank Adrian Farrel and the participants | The authors would like to thank Adrian Farrel and the participants | |||
of ITU-T Study Group 15 Question 14 for their careful review. | of ITU-T Study Group 15 Question 14 for their careful review. The | |||
authors would like to thank the IESG review team for rigorous | ||||
review: special thanks to Tim Polk, Miguel Garcia, Jari Arkko, and | ||||
Dan Romascanu. | ||||
9. References | 9. References | |||
9.1. Normative Reference | 9.1. Normative Reference | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label | [RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Architecture", RFC 3945, October 2004. | Switching (GMPLS) Architecture", RFC 3945, October 2004. | |||
[RFC4202] Kompella, K., and Rekhter, Y., "Routing Extensions in | [RFC4202] Kompella, K., and Rekhter, Y., "Routing Extensions in | |||
Support of Generalized Multi-Protocol Label Switching | Support of Generalized Multi-Protocol Label Switching | |||
(GMPLS)," RFC4202, October 2005. | (GMPLS)," RFC4202, October 2005. | |||
[RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths | [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths | |||
(LSP) Hierarchy with Generalized Multi-Protocol Label | (LSP) Hierarchy with Generalized Multi-Protocol Label | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
Switching (GMPLS) Traffic Engineering (TE)," RFC4206, | Switching (GMPLS) Traffic Engineering (TE)," RFC4206, | |||
Oct. 2005. | Oct. 2005. | |||
[RFC4397] Bryskin, I., and Farrel, A., "A Lexicography for the | [RFC4397] Bryskin, I., and Farrel, A., "A Lexicography for the | |||
Interpretation of Generalized Multiprotocol Label | Interpretation of Generalized Multiprotocol Label | |||
Switching (GMPLS) Terminology within the Context of the | Switching (GMPLS) Terminology within the Context of the | |||
ITU-T's Automatically Switched Optical Network (ASON) | ITU-T's Automatically Switched Optical Network (ASON) | |||
Architecture", RFC 4397, February 2006. | Architecture", RFC 4397, February 2006. | |||
[RFC4726] Farrel, A., Vasseur, JP., and Ayyangar, A., "A | [RFC4726] Farrel, A., Vasseur, JP., and Ayyangar, A., "A | |||
skipping to change at page 23, line 31 | skipping to change at page 22, line 39 | |||
[DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. | [DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. | |||
and Ali, Z., "Procedures for Dynamically Signaled | and Ali, Z., "Procedures for Dynamically Signaled | |||
Hierarchical Label Switched Paths", draft-ietf-ccamp- | Hierarchical Label Switched Paths", draft-ietf-ccamp- | |||
lsp-hierarchy-bis, work in progress. | lsp-hierarchy-bis, work in progress. | |||
[MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, | [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, | |||
D., Shiomoto, K., Vigoureux, M., "Evaluation of | D., Shiomoto, K., Vigoureux, M., "Evaluation of | |||
Existing GMPLS Protocols Against Multi-Layer and | Existing GMPLS Protocols Against Multi-Layer and | |||
Multi-Region Network (MLN/MRN) Requirements", draft- | Multi-Region Network (MLN/MRN) Requirements", draft- | |||
ietf-ccamp-gmpls- mln-eval, work in progress. | ietf-ccamp-gmpls- mln-eval, work in progress. | |||
[MPLS-GMPLS] | ||||
K. Kumaki (Editor), "Interworking Requirements to | [RFC5146] K. Kumaki (Editor), "Interworking Requirements to | |||
Support Operation of MPLS-TE over GMPLS Networks", | Support Operation of MPLS-TE over GMPLS Networks", | |||
draft-ietf-ccamp-mpls-gmpls-interwork-reqts, work in | RFC 5146, March 2008. | |||
progress. | ||||
[MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and | [MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and | |||
GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- | GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- | |||
security-framework, work in progress. | security-framework, work in progress. | |||
[RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized | ||||
Multiprotocol Label Switching (GMPLS) Traffic | ||||
Engineering Management Information Base", RFC 4802, | ||||
February 2007. | ||||
[RFC4803] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized | ||||
Multiprotocol Label Switching (GMPLS) Label Switching | ||||
Router (LSR) Management Information Base", RFC 4803, | ||||
February 2007. | ||||
[RFC4847] T. Takeda (Editor), " Framework and Requirements for | [RFC4847] T. Takeda (Editor), " Framework and Requirements for | |||
Layer 1 Virtual Private Networks", RFC 4847, April | Layer 1 Virtual Private Networks", RFC 4847, April | |||
2007. | 2007. | |||
[RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing | [RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing | |||
Extensions for Discovery of Multiprotocol (MPLS) | Extensions for Discovery of Multiprotocol (MPLS) | |||
Label Switch Router (LSR) Traffic Engineering (TE) | Label Switch Router (LSR) Traffic Engineering (TE) | |||
Mesh Membership", RFC 4972, July 2007. | Mesh Membership", RFC 4972, July 2007. | |||
10. Authors' Addresses | 10. Authors' Addresses | |||
Kohei Shiomoto | Kohei Shiomoto | |||
NTT Network Service Systems Laboratories | NTT Network Service Systems Laboratories | |||
3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan | 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan | |||
Email: shiomoto.kohei@lab.ntt.co.jp | Email: shiomoto.kohei@lab.ntt.co.jp | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
Dimitri Papadimitriou | Dimitri Papadimitriou | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Copernicuslaan 50, | Copernicuslaan 50, | |||
B-2018 Antwerpen, Belgium | B-2018 Antwerpen, Belgium | |||
Phone : +32 3 240 8491 | Phone : +32 3 240 8491 | |||
Email: dimitri.papadimitriou@alcatel-lucent.be | Email: dimitri.papadimitriou@alcatel-lucent.be | |||
Jean-Louis Le Roux | Jean-Louis Le Roux | |||
France Telecom R&D, | France Telecom R&D, | |||
skipping to change at page 25, line 4 | skipping to change at page 24, line 27 | |||
3-9-11 Midori-cho, | 3-9-11 Midori-cho, | |||
Musashino-shi, | Musashino-shi, | |||
Tokyo 180-8585, | Tokyo 180-8585, | |||
Japan | Japan | |||
Phone: +81 422 59 3441 | Phone: +81 422 59 3441 | |||
Email: ichiro.inoue@lab.ntt.co.jp | Email: ichiro.inoue@lab.ntt.co.jp | |||
Emmanuel Dotaro | Emmanuel Dotaro | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Route de Nozay, | Route de Nozay, | |||
draft-ietf-ccamp-gmpls-mln-reqs-08.txt January 2008 | ||||
91461 Marcoussis cedex, | 91461 Marcoussis cedex, | |||
France | France | |||
Phone : +33 1 6963 4723 | Phone : +33 1 6963 4723 | |||
Email: emmanuel.dotaro@alcatel-lucent.fr | Email: emmanuel.dotaro@alcatel-lucent.fr | |||
12. Intellectual Property Considerations | 12. Intellectual Property Considerations | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed | Intellectual Property Rights or other rights that might be claimed | |||
to pertain to the implementation or use of the technology described | to pertain to the implementation or use of the technology described | |||
End of changes. 70 change blocks. | ||||
226 lines changed or deleted | 206 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/ |