draft-ietf-ccamp-gmpls-mln-reqs-06.txt | draft-ietf-ccamp-gmpls-mln-reqs-07.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) | Created: November 7, 2007 Martin Vigoureux (Alcatel-Lucent) | |||
Deborah Brungard (AT&T) | Expires: May 7, 2008 Deborah Brungard (AT&T) | |||
Expires: April 2008 October 2007 | ||||
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-06.txt | draft-ietf-ccamp-gmpls-mln-reqs-07.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 1, line 40 | skipping to change at page 1, line 37 | |||
documents at any time. It is inappropriate to use Internet-Drafts | documents at any time. It is inappropriate to use Internet-Drafts | |||
as reference material or to cite them other than as "work in | as reference material or to cite them other than as "work in | |||
progress." | progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
This Internet-Draft will expire in April 2008. | ||||
Abstract | Abstract | |||
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-06.txt October 2007 | ||||
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/multi-layer networks and lists a set of functional | ||||
requirements. | ||||
Table of Contents | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
1. Introduction .................................................... | ||||
1.1. Scope ........................................................ 2. | ||||
Conventions Used in this Document ............................... 2.1. | ||||
List of Acronyms .............................................. 3. | ||||
Positioning ..................................................... 3.1. | ||||
Data Plane Layers and Control Plane Regions ................... 3.2. | ||||
Service Layer Networks .. ..................................... 3.3. | ||||
Vertical and Horizontal Interaction and Integration ........... 3.4. | ||||
Motivation .................................................... 4. Key | ||||
Concepts of GMPLS-Based MLNs and MRNs ....................... 4.1. | ||||
Interface Switching Capability ................................ 4.2. | ||||
Multiple Interface Switching Capabilities ..................... 4.2.1. | ||||
Networks with Multi-Switching-Type-Capable Hybrid Nodes ..... 4.3. | ||||
Integrated Traffic Engineering (TE) and Resource Control ...... 4.3.1. | ||||
Triggered Signaling ......................................... 4.3.2. | ||||
FA-LSPs ..................................................... 4.3.3. | ||||
Virtual Network Topology (VNT) .............................. 5. | ||||
Requirements .................................................... 5.1. | ||||
Handling Single-Switching and Multi-Switching-Type-Capable | ||||
Nodes ....................................................... 5.2. | ||||
Advertisement of the Available Adjustment Resource ............ 5.3. | ||||
Scalability ................................................... 5.4. | ||||
Stability ..................................................... 5.5. | ||||
Disruption Minimization ....................................... 5.6. | ||||
LSP Attribute Inheritance ..................................... 5.7. | ||||
Computing Paths With and Without Nested Signaling ............. 5.8. | ||||
LSP Resource Utilization ...................................... 5.8.1. | ||||
FA-LSP Release and Setup .................................... 5.8.2. | ||||
Virtual TE-Links ............................................ 5.9. | ||||
Verification of the LSPs ...................................... 6. | ||||
Security Considerations ......................................... 7. | ||||
IANA Considerations ............................................ 8. | ||||
Acknowledgements ................................................ 9. | ||||
References ...................................................... 9.1. | ||||
Normative Reference ........................................... 9.2. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | This document defines a framework for GMPLS based multi-region/ | |||
multi-layer networks and lists a set of functional requirements. | ||||
Informative References ........................................ 10. | Table of Contents | |||
Authors' Addresses ............................................. 11. | ||||
Contributors' Addresses ........................................ 12. | ||||
Intellectual Property Considerations ........................... 13. | ||||
Full Copyright Statement ....................................... | ||||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | 1. Introduction ................................................... 3 | |||
1.1. Scope ........................................................ 4 | ||||
2. Conventions Used in this Document .............................. 5 | ||||
2.1. List of Acronyms ............................................. 5 | ||||
3. Positioning .................................................... 5 | ||||
3.1. Data Plane Layers and Control Plane Regions .................. 6 | ||||
3.2. Service Layer Networks ....................................... 6 | ||||
3.3. Vertical and Horizontal Interaction and Integration .......... 7 | ||||
3.4. Motivation ................................................... 8 | ||||
4. Key Concepts of GMPLS-Based MLNs and MRNs ...................... 9 | ||||
4.1. Interface Switching Capability ............................... 9 | ||||
4.2. Multiple Interface Switching Capabilities ................... 10 | ||||
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes ... 10 | ||||
4.3. Integrated Traffic Engineering (TE) and Resource Control .... 11 | ||||
4.3.1. Triggered Signaling ....................................... 12 | ||||
4.3.2. FA-LSPs ................................................... 12 | ||||
4.3.3. Virtual Network Topology (VNT) ............................ 13 | ||||
5. Requirements .................................................. 14 | ||||
5.1. Handling Single-Switching and Multi-Switching-Type-Capable | ||||
Nodes ....................................................... 14 | ||||
5.2. Advertisement of the Available Adjustment Resource .......... 14 | ||||
5.3. Scalability ................................................. 15 | ||||
5.4. Stability ................................................... 15 | ||||
5.5. Disruption Minimization ..................................... 16 | ||||
5.6. LSP Attribute Inheritance ................................... 16 | ||||
5.7. Computing Paths With and Without Nested Signaling ........... 17 | ||||
5.8. LSP Resource Utilization .................................... 18 | ||||
5.8.1. FA-LSP Release and Setup .................................. 18 | ||||
5.8.2. Virtual TE-Links .......................................... 19 | ||||
5.9. Verification of the LSPs .................................... 20 | ||||
6. Security Considerations ....................................... 20 | ||||
7. IANA Considerations ........................................... 21 | ||||
8. Acknowledgements .............................................. 21 | ||||
9. References .................................................... 21 | ||||
9.1. Normative Reference ......................................... 21 | ||||
9.2. Informative References ...................................... 21 | ||||
10. Authors' Addresses ........................................... 22 | ||||
11. Contributors' Addresses ...................................... 23 | ||||
12. Intellectual Property Considerations ......................... 23 | ||||
13. Full Copyright Statement ..................................... 24 | ||||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
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 45 | skipping to change at page 3, line 44 | |||
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 TE | |||
domain comprising multiple data plane switching layers either of | domain comprising multiple data plane switching layers either of | |||
the same ISC (e.g. TDM) or different ISC (e.g. TDM and PSC) and | the same ISC (e.g. TDM) or different ISC (e.g. TDM and PSC) and | |||
controlled by a single GMPLS control plane instance. We further | controlled by a single GMPLS control plane instance. We further | |||
define a particular case of MLNs. A Multi Region Network (MRN) is | define a particular case of MLNs. A Multi Region Network (MRN) is | |||
defined as a TE domain supporting at least two different switching | defined as a TE domain supporting at least two different switching | |||
technologies (e.g., PSC and TDM) hosted on the same devices | technologies (e.g., PSC and TDM) hosted on the same devices | |||
(referred to as multi-switching-type-capable LSRs, see below) and | (referred to as multi-switching-type-capable LSRs, see below) and | |||
under the control of a single GMPLS control plane instance. | under the 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 | |||
the ISCs among the LSRs: | ISCs among the LSRs: | |||
- Each LSR may support just one ISC. | ||||
Such LSRs are known as single-switching-type-capable LSRs. | - Each LSR may support just one ISC. Such LSRs are known as single- | |||
The MLN may comprise a set of single-switching-type-capable LSRs | switching-type-capable LSRs. The MLN may comprise a set of single- | |||
some of which support different ISCs. | switching-type-capable LSRs 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 | ||||
can be further classified as either "simplex" or "hybrid" nodes | ||||
as defined in Section 4.2. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | - Such LSRs are known as multi-switching-type-capable LSRs, and can | |||
be further classified as either "simplex" or "hybrid" nodes as | ||||
defined in Section 4.2. | ||||
- | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
- - The MLN may be constructed from any combination of single- | ||||
switching-type-capable LSRs and multi-switching-type-capable | - The MLN may be constructed from any combination of single- | |||
LSRs. | switching-type-capable LSRs and multi-switching-type-capable 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 | |||
used to control the MLN/MRN. This enables rapid service | to control the MLN/MRN. This enables rapid service provisioning and | |||
provisioning and efficient traffic engineering across all switching | efficient traffic engineering across all switching capabilities. In | |||
capabilities. In such networks, TE Links are consolidated into a | such networks, TE Links are consolidated into a single Traffic | |||
single Traffic Engineering Database (TED). Since this TED contains | Engineering Database (TED). Since this TED contains the information | |||
the information relative to all the different regions and layers | relative to all the different regions and layers existing in the | |||
existing in the network, a path across multiple regions or layers | network, a path across multiple regions or layers can be computed | |||
can be computed using this TED. Thus optimization of network | using this TED. Thus optimization of network resources can be | |||
resources can be achieved across the whole MLN/MRN. | 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 LSP is routed | |||
between source and destination packet-switch capable routers, and | between source and destination packet-switch capable routers, and | |||
that the LSP can be routed across the PSC-region (i.e., utilizing | that the LSP can be routed across the PSC-region (i.e., utilizing | |||
only resources of the packet region topology). If the performance | only resources of the packet region topology). If the performance | |||
objective for the packet LSP is not satisfied, new TE links may be | objective for the packet LSP is not satisfied, new TE links may be | |||
created between the packet-switch capable routers across the TDM- | created between the packet-switch capable routers across the TDM- | |||
region (for example, VC-12 links) and the LSP can be routed over | region (for example, VC-12 links) and the LSP can be routed over | |||
those TE links. Furthermore, even if the LSP can be successfully | those TE links. Furthermore, even if the LSP can be successfully | |||
established across the PSC-region, TDM hierarchical LSPs across the | established across the PSC-region, TDM hierarchical LSPs across the | |||
TDM region between the packet-switch capable routers may be | TDM region between the packet-switch capable routers may be | |||
established and used if doing so is necessary to meet the | established and used if doing so is necessary to meet the operator's | |||
operator's objectives for network resources availability (e.g., | objectives for network resources availability (e.g., link bandwidth). | |||
link bandwidth.The same considerations hold when VC4 LSPs are | The same considerations hold when VC4 LSPs are provisioned to provide | |||
provisioned to provide extra flexibility for the VC12 and/or VC11 | extra flexibility for the VC12 and/or VC11 layers in an MLN. | |||
layers in an MLN. | ||||
1.1. Scope | 1.1. Scope | |||
This document describes the requirements to support multi-region/ | This document describes the requirements to support multi-region/ | |||
multi-layer networks. There is no intention to specify solution- | multi-layer networks. There is no intention to specify solution- | |||
specific and/or protocol elements in this document. The | specific and/or protocol elements in this document. The applicability | |||
applicability of existing GMPLS protocols and any protocol | of existing GMPLS protocols and any protocol extensions to the | |||
extensions to the MRN/MLN is addressed in separate documents [MRN- | MRN/MLN is addressed in separate documents [MRN-EVAL]. | |||
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-06.txt October 2007 | ||||
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 | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
supporting non-GMPLS interfaces (such as those defined by other | ||||
SDOs), an interworking function may be needed. Location and | For such TE domain to interoperate with edge nodes/domains supporting | |||
specification of this function are outside the scope of this | non-GMPLS interfaces (such as those defined by other SDOs), an | |||
document (because interworking aspects are strictly under the | interworking function may be needed. Location and specification of | |||
responsibility of the interworking function). | this function are outside the scope of this document (because | |||
interworking aspects are strictly under the 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 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", | "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", | |||
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used in | "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used in | |||
skipping to change at page 7, line 4 | skipping to change at page 5, line 51 | |||
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-06.txt October 2007 | ||||
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. | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
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 7, line 24 | skipping to change at page 6, line 22 | |||
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. | |||
The regions that are currently defined are: PSC, L2SC, TDM, LSC, | The regions that are currently defined are: PSC, L2SC, TDM, LSC, | |||
and FSC. Hence, an LSP region is a technology domain (identified by | and FSC. Hence, an LSP region is a technology domain (identified by | |||
the ISC type) for which data plane resources (i.e., data links) are | the ISC type) for which data plane resources (i.e., data links) are | |||
represented into the control plane as an aggregate of TE | represented into the control plane as an aggregate of TE information | |||
information associated with a set of links (i.e., TE links). For | associated with a set of links (i.e., TE links). For example VC-11 | |||
example VC-11 and VC4-64c capable TE links are part of the same TDM | and VC4-64c capable TE links are part of the same TDM region. | |||
region. Multiple layers can thus exist in a single region network. | Multiple layers can thus exist in a single region network. | |||
Note also that the region may produce a distinction within the | Note also that the region may produce a distinction within the | |||
control plane. Layers of the same region share the same switching | control plane. Layers of the same region share the same switching | |||
technology and, therefore, use the same set of technology-specific | technology and, therefore, use the same set of technology-specific | |||
signaling objects and technology-specific value setting of TE link | signaling objects and technology-specific value setting of TE link | |||
attributes within the control plane, but layers from different | attributes within the control plane, but layers from different | |||
regions may use different technology-specific objects and TE | regions may use different technology-specific objects and TE | |||
attribute values. This means that it may not be possible to simply | attribute values. This means that it may not be possible to simply | |||
forward the signaling message between LSR hosting different | forward the signaling message between LSR hosting different | |||
switching technologies because change in some of the signaling | switching technologies because change in some of the signaling | |||
skipping to change at page 8, line 5 | skipping to change at page 6, line 53 | |||
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-06.txt October 2007 | ||||
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 | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
arranged according to the switching capabilities of the devices in | ||||
the networks. Thus, a customer network may be provided on top of | one or more network regions. The network layers are commonly arranged | |||
the GMPLS-based multi-region/multi-layer network. For example, a | according to the switching capabilities of the devices in the | |||
Layer 1 service (realized via the network layers of TDM, and/or LSC, | networks. Thus, a customer network may be provided on top of the | |||
and/or FSC regions) may support a Layer 2 network (realized via ATM | GMPLS-based multi-region/multi-layer network. For example, a Layer 1 | |||
VP/VC) which may itself support a Layer 3 network (IP/MPLS region). | service (realized via the network layers of TDM, and/or LSC, and/or | |||
The supported data plane relationship is a data plane client-server | FSC regions) may support a Layer 2 network (realized via ATM VP/VC) | |||
relationship where the lower layer provides a service for the | which may itself support a Layer 3 network (IP/MPLS region). The | |||
higher layer using the data links realized in the lower layer. | supported data plane relationship is a data plane client-server | |||
relationship where the lower layer provides a service for the higher | ||||
layer using the data links realized in the lower layer. | ||||
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 | |||
pure IP and/or an IP/MPLS network can be provided on top of GMPLS- | IP and/or an IP/MPLS network can be provided on top of GMPLS-based | |||
based packet over optical networks [MPLS-GMPLS]. The relationship | packet over optical networks [MPLS-GMPLS]. The relationship between | |||
between the networks is a client/server relationship and, such | the networks is a client/server relationship and, such services are | |||
services are referred to as "MRN/MLN services". In this case, the | referred to as "MRN/MLN services". In this case, the customer network | |||
customer network may form part of the MRN/MLN, or may be partially | may form part of the MRN/MLN, or may be partially separated, for | |||
separated, for example to maintain separate routing information but | example to maintain separate routing information but retain common | |||
retain common signaling. | 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 one | |||
one layer or region and of realizing the client/server | layer or region and of realizing the client/server relationships | |||
relationships between the layers or regions. Protocol exchanges | between the layers or regions. Protocol exchanges between two network | |||
between two network controllers managing different regions or | controllers managing different regions or layers are also a vertical | |||
layers are also a vertical interaction. Integration of these | interaction. Integration of these interactions as part of the control | |||
interactions as part of the control plane is referred to as | plane is referred to as vertical integration. Thus, this refers to | |||
vertical integration. Thus, this refers to the collaborative | the collaborative mechanisms within a single control plane instance | |||
mechanisms within a single control plane instance driving multiple | driving multiple network layers part of the same region or not. Such | |||
network layers part of the same region or not. Such a concept is | a concept is useful in order to construct a framework that | |||
useful in order to construct a framework that facilitates efficient | facilitates efficient network resource usage and rapid service | |||
network resource usage and rapid service provisioning in carrier | provisioning in carrier networks that are based on multiple layers, | |||
networks that are based on multiple layers, switching technologies, | switching technologies, or ISCs. | |||
or ISCs. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
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 | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
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 | |||
evaluated as part of the inter- domain work [RFC4726], and is | as part of the inter- domain work [RFC4726], and is referred to as | |||
referred to as horizontal integration. Thus, horizontal integration | horizontal integration. Thus, horizontal integration refers to the | |||
refers to the collaborative mechanisms between network partitions | collaborative mechanisms between network partitions and/or | |||
and/or administrative divisions such as routing areas or autonomous | administrative divisions such as routing areas or autonomous systems. | |||
systems. | ||||
This distinction needs further clarification when administrative | This distinction needs further clarification when administrative | |||
domains match layer/region boundaries. Horizontal interaction is | domains match layer/region boundaries. Horizontal interaction is | |||
extended to cover such cases. For example, the collaborative | extended to cover such cases. For example, the collaborative | |||
mechanisms in place between two lambda switching capable areas | mechanisms in place between two lambda switching capable areas relate | |||
relate to horizontal integration. On the other hand, the | to horizontal integration. On the other hand, the collaborative | |||
collaborative mechanisms in place between a packet switching | mechanisms in place between a packet switching capable (e.g., | |||
capable (e.g., IP/MPLS) domain and a separate time division | IP/MPLS) domain and a separate time division switching capable (e.g., | |||
switching capable (e.g., VC4 SDH) domain over which it operates are | VC4 SDH) domain over which it operates are part of the horizontal | |||
part of the horizontal integration while it can also be seen as a | integration while it can also be seen as a first step towards | |||
first step towards vertical integration. | vertical integration. | |||
3.4. Motivation | 3.4. Motivation | |||
The applicability of GMPLS to multiple switching technologies | The applicability of GMPLS to multiple switching technologies | |||
provides a unified control and management approach for both LSP | provides a unified control and management approach for both LSP | |||
provisioning and recovery. Indeed, one of the main motivations for | provisioning and recovery. Indeed, one of the main motivations for | |||
unifying the capabilities and operations of the GMPLS control plane | unifying the capabilities and operations of the GMPLS control plane | |||
is the desire to support multi-LSP-region [RFC4206] routing and | is the desire to support multi-LSP-region [RFC4206] routing and | |||
Traffic Engineering (TE) capabilities. For instance, this enables | Traffic Engineering (TE) capabilities. For instance, this enables | |||
effective network resource utilization of both the Packet/Layer2 | effective network resource utilization of both the Packet/Layer2 | |||
LSP regions and the Time Division Multiplexing (TDM) or Lambda LSP | LSP regions and the Time Division Multiplexing (TDM) or Lambda LSP | |||
regions in high capacity networks. | regions in high capacity networks. | |||
The rationales for GMPLS controlled multi-layer/multi-region | The rationales for GMPLS controlled multi-layer/multi-region networks | |||
networks are summarized below: | are summarized below: | |||
- The maintenance of multiple instances of the control plane on | - The maintenance of multiple instances of the control plane on | |||
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-06.txt October 2007 | ||||
- 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. | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
- 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, | |||
etc.) is facilitated by the capability within GMPLS to associate | etc.) is facilitated by the capability within GMPLS to associate | |||
in-band control plane signaling to the IP terminating interfaces | in-band control plane signaling to the IP terminating interfaces | |||
of the control plane. | of the control plane. | |||
- Resource management and policies to be applied at the edges of | - Resource management and policies to be applied at the edges of | |||
such a MRN/MLN is made more simple (fewer control to management | such a MRN/MLN is made more simple (fewer control to management | |||
skipping to change at page 11, line 5 | skipping to change at page 9, line 48 | |||
[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-06.txt October 2007 | ||||
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. | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
TE link end advertisements may contain multiple ISCDs. This can be | TE link end advertisements may contain multiple ISCDs. This can be | |||
interpreted as advertising a multi-layer (or multi-switching- | interpreted as advertising a multi-layer (or multi-switching- | |||
capable) TE link end. That is, the TE link end (and therefore the | capable) TE link end. That is, the TE link end (and therefore the | |||
TE link) is present in multiple layers. | TE link) is present in multiple layers. | |||
4.2. Multiple Interface Switching Capabilities | 4.2. Multiple Interface Switching Capabilities | |||
In an MLN, network elements may be single-switching-type-capable or | In an MLN, network elements may be single-switching-type-capable or | |||
multi-switching-type-capable nodes. Single-switching-type-capable | multi-switching-type-capable nodes. Single-switching-type-capable | |||
nodes advertise the same ISC value as part of their ISCD sub-TLV(s) | nodes advertise the same ISC value as part of their ISCD sub-TLV(s) | |||
skipping to change at page 11, line 37 | skipping to change at page 10, line 28 | |||
Link(s). This case is described in [RFC4202]. | Link(s). This case is described in [RFC4202]. | |||
Multi-switching-type-capable LSRs are classified as "simplex" or | Multi-switching-type-capable LSRs are classified as "simplex" or | |||
"hybrid" nodes. Simplex and hybrid nodes are categorized according | "hybrid" nodes. Simplex and hybrid nodes are categorized according | |||
to the way they advertise these multiple ISCs: | to the way they advertise these multiple ISCs: | |||
- A simplex node can terminate data links with different switching | - A simplex node can terminate data links with different switching | |||
capabilities where each data link is connected to the node by a | capabilities where each data link is connected to the node by a | |||
separate link interface. So, it advertises several TE Links each | separate link interface. So, it advertises several TE Links each | |||
with a single ISC value carried in its ISCD sub-TLV. For example, | with a single ISC value carried in its ISCD sub-TLV. For example, | |||
an LSR with PSC and TDM links each of which is connected to the | an LSR with PSC and TDM links each of which is connected to the LSR | |||
LSR via a separate interface. | via a separate interface. | |||
- A hybrid node can terminate data links with different switching | - A hybrid node can terminate data links with different switching | |||
capabilities where the data links are connected to the node by | capabilities where the data links are connected to the node by the | |||
the same interface. So, it advertises a single TE Link | same interface. So, it advertises a single TE Link containing more | |||
containing more than one ISCD each with a different ISC value. | than one ISCD each with a different ISC value. For example, a node | |||
For example, a node may terminate PSC and TDM data links and | may terminate PSC and TDM data links and interconnect those | |||
interconnect those external data links via internal links. The | external data links via internal links. The external interfaces | |||
external interfaces connected to the node have both PSC and TDM | connected to the node have both PSC and TDM capabilities. | |||
capabilities. | ||||
Additionally, TE link advertisements issued by a simplex or a | ||||
hybrid node may need to provide information about the node's | ||||
internal adjustment capacity between the switching technologies | ||||
supported. The term "adjustment" capacity refers to the property of | ||||
an hybrid node to interconnect different switching capabilities it | ||||
provides through its external interfaces.. This information allows | ||||
path computation to select an end- to-end multi-layer or multi- | ||||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
region path that includes links of different switching capabilities | Additionally, TE link advertisements issued by a simplex or a hybrid | |||
that are joined by LSRs that can adapt the signal between the links. | node may need to provide information about the node's internal | |||
adjustment capacity between the switching technologies supported. The | ||||
term "adjustment" capacity refers to the property of an hybrid node | ||||
to interconnect different switching capabilities it provides through | ||||
its external interfaces.. This information allows path computation to | ||||
select an end- to-end multi-layer or multi-region path that includes | ||||
links of different switching capabilities 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 | ||||
more simplex nodes, and a set of single-switching-type-capable | This type of network contains at least one hybrid node, zero or more | |||
nodes. | simplex nodes, and a set of single-switching-type-capable 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 | |||
link (Link1 and Link2 respectively). It also has an internal link | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
(Link1 and Link2 respectively). It also has an internal link | ||||
connecting the two switching elements. | connecting the two switching elements. | |||
The two switching elements are internally interconnected in such a | The two switching elements are internally interconnected in such a | |||
way that it is possible to terminate some of the resources of, 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 | |||
connecting the local end of Link2 to the TDM switching element via | the local end of Link2 to the TDM switching element via an additional | |||
an additional interface realizing the termination/adjustment | interface realizing the termination/adjustment function. There are | |||
function. There are two possible ways to set up PSC LSPs through | two possible ways to set up PSC LSPs through the hybrid node. | |||
the hybrid node. Available resource advertisement (i.e., Unreserved | Available resource advertisement (i.e., Unreserved and Min/Max LSP | |||
and Min/Max LSP Bandwidth) should cover both of these methods. | 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 | : | |||
: ---------- : | : ---------- : | |||
:............................ | :............................ | |||
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-06.txt October 2007 | ||||
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 | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
[RFC4206] (see Sections 4.3.2 and 4.3.3). | ||||
- Provisioning of end-to-end LSPs with dynamic triggering of FA | - Dynamic establishment of Forwarding Adjacency (FA) LSPs [RFC4206] | |||
LSPs. | (see Sections 4.3.2 and 4.3.3). | |||
Note that in a multi-layer/multi-region network that includes | - Provisioning of end-to-end LSPs with dynamic triggering of FA LSPs. | |||
multi- switching-type-capable nodes, an explicit route used to | ||||
establish an end-to-end LSP can specify nodes that belong to | Note that in a multi-layer/multi-region network that includes multi- | |||
different layers or regions. In this case, a mechanism to control | switching-type-capable nodes, an explicit route used to establish an | |||
the dynamic creation of FA-LSPs may be required (see Sections 4.3.2 | end-to-end LSP can specify nodes that belong to different layers or | |||
and 4.3.3). | regions. In this case, a mechanism to control the dynamic creation of | |||
FA-LSPs may be required (see Sections 4.3.2 and 4.3.3). | ||||
There is a full spectrum of options to control how FA-LSPs are | There is a full spectrum of options to control how FA-LSPs are | |||
dynamically established. The process can be subject to the control | dynamically established. The process can be subject to the control of | |||
of a policy, which may be set by a management component, and which | a policy, which may be set by a management component, and which may | |||
may require that the management plane is consulted at the time that | require that the management plane is consulted at the time that the | |||
the FA-LSP is established. Alternatively, the FA-LSP can be | FA-LSP is established. Alternatively, the FA-LSP can be established | |||
established at the request of the control plane without any | at the request of the control plane without any management control. | |||
management control. | ||||
4.3.1. Triggered Signaling | 4.3.1. Triggered Signaling | |||
When an LSP crosses the boundary from an upper to a lower layer, it | When an LSP crosses the boundary from an upper to a lower layer, it | |||
may be nested into a lower layer FA-LSP that crosses the lower | may be nested into a lower layer FA-LSP that crosses the lower layer. | |||
layer. From a signaling perspective, there are two alternatives to | From a signaling perspective, there are two alternatives to establish | |||
establish the lower layer FA-LSP: static (pre-provisioned) and | the lower layer FA-LSP: static (pre-provisioned) and dynamic | |||
dynamic (triggered). A pre-provisioned FA-LSP may be initiated | (triggered). A pre-provisioned FA-LSP may be initiated either by the | |||
either by the operator or automatically using features like TE | operator or automatically using features like TE auto-mesh [RFC4972]. | |||
auto-mesh [RFC4972]. If such a lower layer LSP does not already | If such a lower layer LSP does not already exist, the LSP may be | |||
exist, the LSP may be established dynamically. Such a mechanism is | established dynamically. Such a mechanism is referred to as | |||
referred to as "triggered signaling". | "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 | ||||
nodes to consider the LSP as a TE link for their path computation | ||||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
Furthermore, it can be advertised as a TE-link, allowing other nodes | ||||
to consider the LSP as a TE link for their path computation | ||||
[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 | |||
link is called a Forwarding Adjacency (FA). An FA has the special | 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 | |||
between its end points yet still guaranteeing control plane | its end points yet still guaranteeing control plane connectivity | |||
connectivity between the FA-LSP end points based on a signaling | between the FA-LSP end points based on a signaling adjacency. An FA | |||
adjacency. An FA is a useful and powerful tool for improving the | is a useful and powerful tool for improving the scalability of GMPLS | |||
scalability of GMPLS Traffic Engineering (TE) capable networks | Traffic Engineering (TE) capable networks since multiple higher layer | |||
since multiple higher layer LSPs may be nested (aggregated) over a | LSPs may be nested (aggregated) over a single FA-LSP. | |||
single FA-LSP. | ||||
The aggregation of LSPs enables the creation of a vertical (nested) | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
LSP Hierarchy. A set of FA-LSPs across or within a lower layer can | ||||
be used during path selection by a higher layer LSP. Likewise, the | ||||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
higher layer LSPs may be carried over dynamic data links realized | The aggregation of LSPs enables the creation of a vertical (nested) | |||
via LSPs (just as they are carried over any "regular" static data | LSP Hierarchy. A set of FA-LSPs across or within a lower layer can be | |||
links). This process requires the nesting of LSPs through a | used during path selection by a higher layer LSP. Likewise, the | |||
hierarchical process [RFC4206]. The TED contains a set of LSP | higher layer LSPs may be carried over dynamic data links realized via | |||
advertisements from different layers that are identified by the | LSPs (just as they are carried over any "regular" static data links). | |||
ISCD contained within the TE link advertisement associated with the | This process requires the nesting of LSPs through a hierarchical | |||
LSP [RFC4202]. | process [RFC4206]. The TED contains a set of LSP advertisements from | |||
different layers that are identified by the ISCD contained within the | ||||
TE link advertisement associated with the LSP [RFC4202]. | ||||
If a lower layer LSP is not advertised as an FA, it can still be | If a lower layer LSP is not advertised as an FA, it can still be used | |||
used to carry higher layer LSPs across the lower layer. For example, | to carry higher layer LSPs across the lower layer. For example, if | |||
if the LSP is set up using triggered signaling, it will be used to | the LSP is set up using triggered signaling, it will be used to carry | |||
carry the higher layer LSP that caused the trigger. Further, the | the higher layer LSP that caused the trigger. Further, the lower | |||
lower layer remains available for use by other higher layer LSPs | layer remains available for use by other higher layer LSPs arriving | |||
arriving at the boundary. | at the boundary. | |||
Under some circumstances it may be useful to control the | Under some circumstances it may be useful to control the | |||
advertisement of LSPs as FAs during the signaling establishment of | advertisement of LSPs as FAs during the signaling establishment of | |||
the LSPs [DYN-HIER]. | the LSPs [DYN-HIER]. | |||
4.3.3. Virtual Network Topology (VNT) | 4.3.3. Virtual Network Topology (VNT) | |||
A set of one or more of lower-layer LSPs provides information for | A set of one or more of lower-layer LSPs provides information for | |||
efficient path handling in upper-layer(s) of the MLN, or, in other | efficient path handling in upper-layer(s) of the MLN, or, in other | |||
words, provides a virtual network topology (VNT) to the upper- | words, provides a virtual network topology (VNT) to the upper-layers. | |||
layers. For instance, a set of LSPs, each of which is supported by | For instance, a set of LSPs, each of which is supported by an LSC | |||
an LSC LSP, provides a virtual network topology to the layers of a | LSP, provides a virtual network topology to the layers of a PSC | |||
PSC region, assuming that the PSC region is connected to the LSC | region, assuming that the PSC region is connected to the LSC region. | |||
region. Note that a single lower-layer LSP is a special case of the | Note that a single lower-layer LSP is a special case of the VNT. The | |||
VNT. The virtual network topology is configured by setting up or | virtual network topology is configured by setting up or tearing down | |||
tearing down the lower layer LSPs. By using GMPLS signaling and | the lower layer LSPs. By using GMPLS signaling and routing protocols, | |||
routing protocols, the virtual network topology can be adapted to | the virtual network topology can be adapted to traffic demands. | |||
traffic demands. | ||||
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 | |||
important information that is needed to make the higher-layer LSPs | information that is needed to make the higher-layer LSPs reliable. | |||
reliable. For instance, the routing and traffic engineering in the | For instance, the routing and traffic engineering in the IP/MPLS | |||
IP/MPLS layer does not usually consider how the IP/MPLS TE links | layer does not usually consider how the IP/MPLS TE links are formed | |||
are formed from optical paths that are routed in the fiber layer. | from optical paths that are routed in the fiber layer. Two optical | |||
Two optical paths may share the same fiber link in the lower-layer | paths may share the same fiber link in the lower-layer and therefore | |||
and therefore they may both fail if the fiber link is cut. Thus the | they may both fail if the fiber link is cut. Thus the shared risk | |||
shared risk properties of the TE links in the VNT must be made | properties of the TE links in the VNT must be made available to the | |||
available to the higher layer during path computation. Further, the | higher layer during path computation. Further, the topology of the | |||
topology of the VNT should be designed so that any single fiber cut | VNT should be designed so that any single fiber cut does not bisect | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
does not bisect the VNT. These issues are addressed later in this | the VNT. These issues are addressed later in this document. | |||
document. | ||||
Reconfiguration of the virtual network topology may be triggered by | Reconfiguration of the virtual network topology may be triggered by | |||
traffic demand changes, topology configuration changes, signaling | traffic demand changes, topology configuration changes, signaling | |||
requests from the upper layer, and network failures. For instance, | requests from the upper layer, and network failures. For instance, | |||
by reconfiguring the virtual network topology according to the | by reconfiguring the virtual network topology according to the | |||
traffic demand between source and destination node pairs, network | traffic demand between source and destination node pairs, network | |||
performance factors, such as maximum link utilization and residual | performance factors, such as maximum link utilization and residual | |||
capacity of the network, can be optimized. Reconfiguration is | capacity of the network, can be optimized. Reconfiguration is | |||
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) and SHOULD advertise | |||
advertise the resource information for those links. Likewise, path | the resource information for those links. Likewise, path computation | |||
computation elements SHOULD be prepared to use the availability of | elements SHOULD be prepared to use the availability of termination/ | |||
termination/ adjustment resources as a constraint in MRN/MLN path | adjustment resources as a constraint in MRN/MLN path computations to | |||
computations to reduce the higher layer LSP setup blocking | reduce the higher layer LSP setup blocking probability caused by the | |||
probability caused by the lack of necessary termination/adjustment | lack of necessary termination/adjustment resources in the lower | |||
resources in the lower layer(s). | 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 | |||
as it provides critical information when performing multi-region | it provides critical information when performing multi-region path | |||
path computation. | computation. | |||
The mechanism SHOULD cover the case where the upper-layer links | The mechanism SHOULD cover the case where the upper-layer links which | |||
which are directly connected to upper-layer switching element and | are directly connected to upper-layer switching element and the ones | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | which are connected through internal links between upper-layer | |||
element and lower-layer element coexist (see Section 4.2.1). | ||||
the ones which are connected through internal links between upper- | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
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 | |||
plane model removes the requirement to maintain a dedicated | model removes the requirement to maintain a dedicated routing | |||
routing topology per layer, and therefore does not mandate a | topology per layer, and therefore does not mandate a full mesh of | |||
full mesh of routing adjacencies per layer. | 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 | |||
has to be flooded and stored within the network. | 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 | |||
importance during restoration, will depend on the size of the TED. | during restoration, will depend on the size of the TED. | |||
Thus MRN/MLN routing mechanisms MUST be designed to scale well with | Thus MRN/MLN routing mechanisms MUST be designed to scale well with | |||
an increase of any of the following: | an increase of any of the following: | |||
- 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 | |||
mechanism and the signaling protocol SHOULD be able to operate on | and the signaling protocol SHOULD be able to operate on partial TE | |||
partial TE information. | information. | |||
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 VNT | 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 | |||
topological maps leads us to consider the concept of emulation of | maps leads us to consider the concept of emulation of data plane | |||
data plane overlays. | 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 | |||
associated link state. The path computation stability of an upper | link state. The path computation stability of an upper layer may be | |||
layer may be impaired if the VNT changes frequently and/or if the | impaired if the VNT changes frequently and/or if the status and TE | |||
status and TE parameters (the TE metric, for instance) of links in | parameters (the TE metric, for instance) of links in the VNT changes | |||
the VNT changes frequently. In this context, robustness of the VNT | frequently. In this context, robustness of the VNT is defined as the | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | capability to smooth changes that may occur and avoid their | |||
propagation into higher layers. Changes to the VNT may be caused by | ||||
the creation, deletion, or modification of LSPs. | ||||
is defined as the capability to smooth changes that may occur and | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
avoid their propagation into higher layers. Changes to the VNT may | ||||
be caused by the creation, deletion, or modification of LSPs. | ||||
Creation, deletion, and modification of LSPs MAY be triggered by | Creation, deletion, and modification of LSPs MAY be triggered by | |||
adjacent layers or through operational actions to meet traffic | adjacent layers or through operational actions to meet traffic demand | |||
demand changes, topology changes, signaling requests from the upper | changes, topology changes, signaling requests from the upper layer, | |||
layer, and network failures. Routing robustness SHOULD be traded | and network failures. Routing robustness SHOULD be traded with | |||
with adaptability with respect to the change of incoming traffic | adaptability with respect to the change of incoming traffic requests. | |||
requests. | ||||
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 | |||
upper layers MUST be minimized. | 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 | |||
layer LSPs MAY be released according to local or network policies. | LSPs MAY be released according to local or network policies. There is | |||
There is a trade-off between minimizing the amount of resource | a trade-off between minimizing the amount of resource reserved in the | |||
reserved in the lower layer and disrupting higher layer traffic | lower layer and disrupting higher layer traffic (i.e., moving the | |||
(i.e. moving the traffic to other TE-LSPs so that some LSPs can be | traffic to other TE-LSPs so that some LSPs can be released). Such | |||
released). Such traffic disruption MAY be allowed, but MUST be | traffic disruption MAY be allowed, but MUST be under the control of | |||
under the control of policy that can be configured by the operator. | policy that can be configured by the operator. Any repositioning of | |||
Any repositioning of traffic MUST be as non-disruptive as possible | traffic MUST be as non-disruptive as possible (for example, using | |||
(for example, using make-before-break). | 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 | |||
LSP that provides the TE-link, and so from the TE-links in the | that provides the TE-link, and so from the TE-links in the lower | |||
lower layer that are traversed by the LSP. | layer that are traversed by the LSP. | |||
These include: | These include: | |||
- 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 | |||
metric (which may be other than a strict sum of the metrics of the | (which may be other than a strict sum of the metrics of the component | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | TE links at the lower layer), protection attributes, and SRLG. | |||
component TE links at the lower layer), protection attributes, and | ||||
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 | |||
layer network reliable. SRLGs may be used to identify which lower- | network reliable. SRLGs may be used to identify which lower-layer | |||
layer LSPs share the same failure risk so that the potential risk | LSPs share the same failure risk so that the potential risk of the | |||
of the VNT becoming disjoint can be minimized, and so that resource | VNT becoming disjoint can be minimized, and so that resource disjoint | |||
disjoint protection paths can be set up in the higher layer. How to | protection paths can be set up in the higher layer. How to inherit | |||
inherit the SRLG information from the lower layer to the upper | draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | |||
layer needs more discussion and is out of scope of this document. | ||||
the SRLG information from the lower layer to the upper 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 MAY 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. For example, path | |||
computation MAY restrict the path taken by an LSP to only the links | computation MAY restrict the path taken by an LSP to only the links | |||
whose interface switching capability is PSC. | whose interface switching capability is PSC. | |||
Interface switching capability is used as a constraint in path | Interface switching capability is used as a constraint in path | |||
computation. For example, a TDM-LSP is routed over the topology | computation. For example, a TDM-LSP is routed over the topology | |||
composed of TE links of the same TDM layer. In calculating the path | composed of TE links of the same TDM layer. In calculating the path | |||
for the LSP, the TED MAY be filtered to include only links where | for the LSP, the TED MAY be filtered to include only links where both | |||
both end include requested LSP switching type. In this way | end include requested LSP switching type. In this way hierarchical | |||
hierarchical routing is done by using a TED filtered with respect | routing is done by using a TED filtered with respect to switching | |||
to switching capability (that is, with respect to particular layer). | 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 | |||
MAY produce a route containing multiple layers/regions. The path is | 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 | |||
to make the path "connected", when the upper-layer signaling | make the path "connected", when the upper-layer signaling request | |||
request arrives at the boundary node. | 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 that includes | |||
only hops in the upper layer, in which case the boundary node is | only hops in the upper layer, in which case the boundary node is | |||
responsible for triggered creation of the lower-layer FA-LSP using | responsible for triggered creation of the lower-layer FA-LSP using a | |||
a path of its choice, or for the selection of any available lower | path of its choice, or for the selection of any available lower layer | |||
layer LSP as a data link for the higher layer. This mechanism is | LSP as a data link for the higher layer. This mechanism is | |||
appropriate for environments where the TED is filtered in the | appropriate for environments where the TED is filtered in the higher | |||
higher layer, where separate routing instances are used per layer, | layer, where separate routing instances are used per layer, or where | |||
or where administrative policies prevent the higher layer from | administrative policies prevent the higher layer from specifying | |||
specifying paths through the lower layer. | 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 | |||
indicate the lower layer resources to be used. But in this case, | the lower layer resources to be used. But in this case, the path of | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | the lower layer LSP can be dynamically changed by the lower layer at | |||
any time. | ||||
the path of the lower layer LSP can be dynamically changed by the | ||||
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 is responsible for decision as to which it should use the path | |||
contained in the strict ERO or it should re-compute the path within | contained in the strict ERO or it should re-compute the path within | |||
in the lower-layer. | in the lower-layer. | |||
Even in case the lower-layer FA-LSPs are already established, a | Even in case the lower-layer FA-LSPs are already established, a | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
signaling request may also be encoded as loose ERO. In this | signaling request may also be encoded as loose ERO. In this | |||
situation, it is up to the boundary node to decide whether it | situation, it is up to the boundary node to decide whether it should | |||
should a new lower-layer FA-LSP or it should use the existing | a new lower-layer FA-LSP or it should use the existing lower-layer | |||
lower-layer FA-LSPs. | 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 | |||
layer FA-LSP. | FA-LSP. | |||
5.8. LSP Resource Utilization | 5.8. LSP Resource Utilization | |||
It MUST be possible to utilize network resources efficiently. | It MUST be possible to utilize network resources efficiently. | |||
Particularly, resource usage in all layers SHOULD be optimized as a | Particularly, resource usage in all layers SHOULD be optimized as a | |||
whole (i.e., across all layers), in a coordinated manner, (i.e., | whole (i.e., across all layers), in a coordinated manner, (i.e., | |||
taking all layers into account). The number of lower-layer LSPs | taking all layers into account). The number of lower-layer LSPs | |||
carrying upper-layer LSPs SHOULD be minimized (note that multiple | carrying upper-layer LSPs SHOULD be minimized (note that multiple | |||
LSPs MAY be used for load balancing). Lower-layer LSPs that could | LSPs MAY be used for load balancing). Lower-layer LSPs that could | |||
have their traffic re-routed onto other LSPs are unnecessary and | have their traffic re-routed onto other LSPs are unnecessary and | |||
SHOULD be 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 | Statistical multiplexing can only be employed in PSC and L2SC | |||
regions. A PSC or L2SC LSP may or may not consume the maximum | 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 | reservable bandwidth of the TE link (FA-LSP) that carries it. On the | |||
the other hand, a TDM, or LSC LSP always consumes a fixed amount of | other hand, a TDM, or LSC LSP always consumes a fixed amount of | |||
bandwidth as long as it exists (and is fully instantiated) because | bandwidth as long as it exists (and is fully instantiated) because | |||
statistical multiplexing is not available. | 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 | |||
the nested LSPs can also be re-routed to other FA-LSPs (optionally | nested LSPs can also be re-routed to other FA-LSPs (optionally using | |||
using the make-before-break technique) to completely free up the | the make-before-break technique) to completely free up the FA-LSP. | |||
FA-LSP. Alternatively, unused FA-LSPs MAY be retained for future | Alternatively, unused FA-LSPs MAY be retained for future use. Release | |||
use. Release or retention of underutilized FA-LSPs is a policy | or retention of underutilized FA-LSPs is a policy decision. | |||
decision. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
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 | |||
such as maximum residual capacity may increase. | as maximum residual capacity may increase. | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
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 | |||
to policy. | 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- | |||
pre- provision) the set of lower layer LSPs that provide the VNT | provision) the set of lower layer LSPs that provide the VNT since | |||
since this might reserve bandwidth that could be used for other | this might reserve bandwidth that could be used for other LSPs in the | |||
LSPs in the absence of upper-layer traffic. | 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 | |||
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 | |||
computed paths while wastage of bandwidth within the lower-layer | paths while wastage of bandwidth within the lower-layer and | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | unnecessary reservation of adaptation resource at the border nodes | |||
can be avoided. | ||||
and unnecessary reservation of adaptation resource at the border | ||||
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 | |||
of such virtual TE-links, taking into account the (forecast) | such virtual TE-links, taking into account the (forecast) traffic | |||
traffic demand and available resource in the lower-layer. | demand and available resource in the lower-layer. | |||
Virtual TE-links MAY be added, removed or modified dynamically (by | Virtual TE-links MAY 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. The | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
maximum number of virtual TE links that can be defined SHOULD be | maximum number of virtual TE links that can be defined SHOULD be | |||
configurable. | configurable. | |||
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 | |||
links to form part of the VNT. The combination of the fully | to form part of the VNT. The combination of the fully provisioned TE- | |||
provisioned TE- links and the virtual TE-links defines the VNT | links and the virtual TE-links defines the VNT provided by the lower | |||
provided by the lower layer. The VNT can be changed by setting up | layer. The VNT can be changed by setting up and/or tearing down | |||
and/or tearing down virtual TE links as well as by modifying real | virtual TE links as well as by modifying real links (i.e., the fully | |||
links (i.e., the fully provisioned LSPs). How to design the VNT and | provisioned LSPs). How to design the VNT and how to manage it are out | |||
how to manage it are out of scope of this document. | of scope of this document. | |||
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. Such mechanisms are data technology-specific and are | |||
are beyond the scope of this document, but may be coordinated | beyond the scope of this document, but may be coordinated through the | |||
through the GMPLS control plane. | GMPLS control plane. | |||
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 | |||
operated as different administrative domains, additional security | as different administrative domains, additional security | |||
considerations may be given to the mechanisms for allowing inter- | considerations may be given to the mechanisms for allowing inter- | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
layer LSP setup, for triggering lower-layer LSPs, or for VNT | layer LSP setup, for triggering lower-layer LSPs, or for VNT | |||
management. Similarly, consideration may be given to the amount of | management. Similarly, consideration may be given to the amount of | |||
information shared between administrative domains, and the trade- | information shared between administrative domains, and the trade- | |||
off between multi-layer TE and confidentiality of information | off between multi-layer TE and confidentiality of information | |||
belonging to each administrative domain. | belonging to each administrative domain. | |||
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. | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
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. | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
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 | ||||
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. | |||
[RFC4726] Farrel, A., Vasseur, JP., and Ayyangar, A., "A | ||||
Framework for Inter-Domain Multiprotocol Label | ||||
Switching Traffic Engineering", RFC 4726, November 2006. | ||||
[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 | |||
Switching (GMPLS) Traffic Engineering (TE)," RFC4206, | Switching (GMPLS) Traffic Engineering (TE)," RFC4206, | |||
Oct. 2005. | October 2005. | |||
[RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label | ||||
Switching (GMPLS) Architecture", RFC 3945, October 2004. | ||||
[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 | ||||
Framework for Inter-Domain Multiprotocol Label | ||||
Switching Traffic Engineering", RFC 4726, November 2006. | ||||
9.2. Informative References | 9.2. Informative References | |||
[MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, | [DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and | |||
D., Shiomoto, K., Vigoureux, M., "Evaluation of | Ali, Z., "Procedures for Dynamically Signaled | |||
Existing GMPLS Protocols Against Multi-Layer and | Hierarchical Label Switched Paths", | |||
Multi-Region Network (MLN/MRN) Requirements", draft- | draft-ietf-ccamp-lsp-hierarchy-bis, work in progress. | |||
ietf-ccamp-gmpls- mln-eval, work in progress. | ||||
[MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., | ||||
Shiomoto, K., Vigoureux, M., "Evaluation of Existing | ||||
GMPLS Protocols Against Multi-Layer and Multi-Region | ||||
Network (MLN/MRN) Requirements", | ||||
draft-ietf-ccamp-gmpls-mln-eval, work in progress. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
[MPLS-GMPLS] K. Kumaki (Editor), "Interworking Requirements to | [MPLS-GMPLS] 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 | draft-ietf-ccamp-mpls-gmpls-interwork-reqts, work in | |||
progress. | progress. | |||
[DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. | ||||
and Ali, Z., "Procedures for Dynamically Signaled | ||||
Hierarchical Label Switched Paths", draft-ietf-ccamp- | ||||
lsp-hierarchy-bis, work in 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-fang-mpls-gmpls-security- | GMPLS Networks", | |||
framework, work in progress. | draft-ietf-mpls-mpls-and-gmpls-security-framework, work in | |||
progress. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | [RFC4847] T. Takeda (Editor), " Framework and Requirements for Layer | |||
1 Virtual Private Networks", RFC 4847, April 2007. | ||||
[RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing | [RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing Extensions | |||
Extensions for Discovery of Multiprotocol (MPLS) | for Discovery of Multiprotocol (MPLS) Label Switch Router | |||
Label Switch Router (LSR) Traffic Engineering (TE) | (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, | |||
Mesh Membership", RFC 4972, July 2007. | July 2007. | |||
[RFC4847] T. Takeda (Editor), " Framework and Requirements for | ||||
Layer 1 Virtual Private Networks", RFC 4847, April | ||||
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 | |||
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, | |||
Av Pierre Marzin, | Av Pierre Marzin, 22300 Lannion, France | |||
22300 Lannion, France | ||||
Email: jeanlouis.leroux@orange-ft.com | Email: jeanlouis.leroux@orange-ft.com | |||
Martin Vigoureux | Martin Vigoureux | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Route de Nozay, 91461 Marcoussis cedex, France | Route de Nozay, 91461 Marcoussis cedex, France | |||
Phone: +33 (0)1 69 63 18 52 | Phone: +33 (0)1 69 63 18 52 | |||
Email: martin.vigoureux@alcatel-lucent.fr | Email: martin.vigoureux@alcatel-lucent.fr | |||
Deborah Brungard | Deborah Brungard | |||
AT&T | AT&T | |||
Rm. D1-3C22 - 200 | Rm. D1-3C22 - 200 | |||
S. Laurel Ave., Middletown, NJ 07748, USA | S. Laurel Ave., Middletown, NJ 07748, USA | |||
Phone: +1 732 420 1573 | Phone: +1 732 420 1573 | |||
Email: dbrungard@att.com | Email: dbrungard@att.com | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
11. Contributors' Addresses | 11. Contributors' Addresses | |||
Eiji Oki | Eiji Oki | |||
NTT Network Service Systems Laboratories | NTT Network Service Systems Laboratories | |||
3-9-11 Midori-cho, Musashino-shi, | 3-9-11 Midori-cho, Musashino-shi, | |||
Tokyo 180-8585, | Tokyo 180-8585, Japan | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
Japan | ||||
Phone: +81 422 59 3441 | Phone: +81 422 59 3441 | |||
Email: oki.eiji@lab.ntt.co.jp | Email: oki.eiji@lab.ntt.co.jp | |||
Ichiro Inoue | Ichiro Inoue | |||
NTT Network Service Systems Laboratories | NTT Network Service Systems Laboratories | |||
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, | |||
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 | |||
in this document or the extent to which any license under such | in this document or the extent to which any license under such | |||
rights might or might not be available; nor does it represent that | rights might or might not be available; nor does it represent that | |||
skipping to change at page 26, line 51 | skipping to change at page 24, line 5 | |||
of such proprietary rights by implementers or users of this | of such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository | specification can be obtained from the IETF on-line IPR repository | |||
at http://www.ietf.org/ipr. | at http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at ietf- | |||
ipr@ietf.org. | ipr@ietf.org. | |||
draft-ietf-ccamp-gmpls-mln-reqs-07.txt November 2007 | ||||
13. Full Copyright Statement | 13. Full Copyright Statement | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
This document and the information contained herein are provided on | This document and the information contained herein are provided on | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | |||
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | |||
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | |||
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | |||
End of changes. 120 change blocks. | ||||
457 lines changed or deleted | 435 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/ |