draft-ietf-ccamp-gmpls-mln-reqs-05.txt | draft-ietf-ccamp-gmpls-mln-reqs-06.txt | |||
---|---|---|---|---|
Network Working Group Kohei Shiomoto (NTT) | Network Working Group Kohei Shiomoto (NTT) | |||
Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) | Internet-Draft Dimitri Papadimitriou (Alcatel-Lucent) | |||
Intended Status: Informational Jean-Louis Le Roux (France Telecom) | Intended Status: Informational Jean-Louis Le Roux (France Telecom) | |||
Martin Vigoureux (Alcatel-Lucent) | Martin Vigoureux (Alcatel-Lucent) | |||
Deborah Brungard (AT&T) | Deborah Brungard (AT&T) | |||
Expires: February 2008 August 2007 | 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-05.txt | draft-ietf-ccamp-gmpls-mln-reqs-06.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 | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six | |||
and may be updated, replaced, or obsoleted by other documents at any | months and may be updated, replaced, or obsoleted by other | |||
time. It is inappropriate to use Internet-Drafts as reference | documents at any time. It is inappropriate to use Internet-Drafts | |||
material or to cite them other than as "work in progress." | as reference material or to cite them other than as "work in | |||
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 February 2008. | This Internet-Draft will expire in April 2008. | |||
Abstract | Abstract | |||
Most of the initial efforts to utilize Generalized MPLS (GMPLS) have | Most of the initial efforts to utilize Generalized MPLS (GMPLS) | |||
been related to environments hosting devices with a single switching | have been related to environments hosting devices with a single | |||
capability. The complexity raised by the control of such data planes | switching capability. The complexity raised by the control of such | |||
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-layered | provides a comprehensive framework for the control of a multi- | |||
network of either a single switching technology or multiple switching | layered network of either a single switching technology or multiple | |||
technologies. | switching technologies. | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | 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). This | regions, this document uses the term, Multi-Layer Network (MLN). | |||
document defines a framework for GMPLS based multi-region/multi-layer | This document defines a framework for GMPLS based multi- | |||
networks and lists a set of functional requirements. | region/multi-layer networks and lists a set of functional | |||
requirements. | ||||
Table of Contents | Table of Contents | |||
1. Introduction .................................................... | 1. Introduction .................................................... | |||
1.1. Scope ......................................................... | 1.1. Scope ........................................................ 2. | |||
2. Conventions Used in this Document ............................... | Conventions Used in this Document ............................... 2.1. | |||
2.1. List of Acronyms .............................................. | List of Acronyms .............................................. 3. | |||
3. Positioning ..................................................... | Positioning ..................................................... 3.1. | |||
3.1. Data Plane Layers and Control Plane Regions ................... | Data Plane Layers and Control Plane Regions ................... 3.2. | |||
3.2. Service Layer Networks .. ..................................... | Service Layer Networks .. ..................................... 3.3. | |||
3.3. Vertical and Horizontal Interaction and Integration ........... | Vertical and Horizontal Interaction and Integration ........... 3.4. | |||
3.4. Motivation .................................................... | Motivation .................................................... 4. Key | |||
4. Key Concepts of GMPLS-Based MLNs and MRNs ....................... | Concepts of GMPLS-Based MLNs and MRNs ....................... 4.1. | |||
4.1. Interface Switching Capability ................................ | Interface Switching Capability ................................ 4.2. | |||
4.2. Multiple Interface Switching Capabilities ..................... | Multiple Interface Switching Capabilities ..................... 4.2.1. | |||
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes ..... | Networks with Multi-Switching-Type-Capable Hybrid Nodes ..... 4.3. | |||
4.3. Integrated Traffic Engineering (TE) and Resource Control ...... | Integrated Traffic Engineering (TE) and Resource Control ...... 4.3.1. | |||
4.3.1. Triggered Signaling ......................................... | Triggered Signaling ......................................... 4.3.2. | |||
4.3.2. FA-LSPs ..................................................... | FA-LSPs ..................................................... 4.3.3. | |||
4.3.3. Virtual Network Topology (VNT) .............................. | Virtual Network Topology (VNT) .............................. 5. | |||
5. Requirements .................................................... | Requirements .................................................... 5.1. | |||
5.1. Handling Single-Switching and Multi-Switching-Type-Capable | Handling Single-Switching and Multi-Switching-Type-Capable | |||
Nodes ....................................................... | Nodes ....................................................... 5.2. | |||
5.2. Advertisement of the Available Adaptation Resource ............ | Advertisement of the Available Adjustment Resource ............ 5.3. | |||
5.3. Scalability ................................................... | Scalability ................................................... 5.4. | |||
5.4. Stability ..................................................... | Stability ..................................................... 5.5. | |||
5.5. Disruption Minimization ....................................... | Disruption Minimization ....................................... 5.6. | |||
5.6. LSP Attribute Inheritance ..................................... | LSP Attribute Inheritance ..................................... 5.7. | |||
5.7. Computing Paths With and Without Nested Signaling ............. | Computing Paths With and Without Nested Signaling ............. 5.8. | |||
5.8. LSP Resource Utilization ...................................... | LSP Resource Utilization ...................................... 5.8.1. | |||
5.8.1. FA-LSP Release and Setup .................................... | FA-LSP Release and Setup .................................... 5.8.2. | |||
5.8.2. Virtual TE-Links ............................................ | Virtual TE-Links ............................................ 5.9. | |||
5.9. Verification of the LSPs ...................................... | Verification of the LSPs ...................................... 6. | |||
6. Security Considerations ......................................... | Security Considerations ......................................... 7. | |||
7. IANA Considerations ............................................ | IANA Considerations ............................................ 8. | |||
8. Acknowledgements ................................................ | Acknowledgements ................................................ 9. | |||
9. References ...................................................... | References ...................................................... 9.1. | |||
9.1. Normative Reference ........................................... | Normative Reference ........................................... 9.2. | |||
9.2. Informative References ........................................ | ||||
10. Authors' Addresses ............................................. | ||||
11. Contributors' Addresses ........................................ | ||||
12. Intellectual Property Considerations ........................... | ||||
13. Full Copyright Statement ....................................... | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
Informative References ........................................ 10. | ||||
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 | 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 these | Interface Switching Capability (ISC) concept is introduced for | |||
switching technologies and is designated as follows: PSC (packet | these switching technologies and is designated as follows: PSC | |||
switch capable), L2SC (Layer-2 switch capable), TDM (Time Division | (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | |||
Multiplex capable), LSC (lambda switch capable), and FSC (fiber | Division Multiplex capable), LSC (lambda switch capable), and FSC | |||
switch capable). | (fiber switch capable). | |||
The representation, in a GMPLS control plane, of a switching | The representation, in a GMPLS control plane, of a switching | |||
technology domain is referred to as a region [RFC4206]. A switching | technology domain is referred to as a region [RFC4206]. A switching | |||
type describes the ability of a node to forward data of a particular | type describes the ability of a node to forward data of a | |||
data plane technology, and uniquely identifies a network region. A | particular data plane technology, and uniquely identifies a network | |||
layer describes a data plane switching granularity level (e.g., VC4, | region. A layer describes a data plane switching granularity level | |||
VC-12). A data plane layer is associated with a region in the control | (e.g., VC4, VC-12). A data plane layer is associated with a region | |||
plane (e.g., VC4 is associated with TDM, MPLS is associated with | in the control plane (e.g., VC4 is associated with TDM, MPLS is | |||
PSC). However, more than one data plane layer can be associated with | associated with PSC). However, more than one data plane layer can | |||
the same region (e.g., both VC4 and VC12 are associated with TDM). | be associated with the same region (e.g., both VC4 and VC12 are | |||
Thus, a control plane region, identified by its switching type value | associated with TDM). Thus, a control plane region, identified by | |||
(e.g., TDM), can be sub-divided into smaller granularity component | its switching type value (e.g., TDM), can be sub-divided into | |||
networks based on "data plane switching layers". The Interface | smaller granularity component networks based on "data plane | |||
Switching Capability Descriptor (ISCD) [RFC4202], identifying the | switching layers". The Interface Switching Capability Descriptor | |||
interface switching capability (ISC), the encoding type, and the | (ISCD) [RFC4202], identifying the interface switching capability | |||
switching bandwidth granularity, enables the characterization of the | (ISC), the encoding type, and the switching bandwidth granularity, | |||
associated layers. | enables the characterization of the associated layers. | |||
In this document, we define a Multi Layer Network (MLN) to be a TE | In this document, we define a Multi Layer Network (MLN) to be a TE | |||
domain comprising multiple data plane switching layers either of the | domain comprising multiple data plane switching layers either of | |||
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 (referred | technologies (e.g., PSC and TDM) hosted on the same devices | |||
to as multi-switching-type-capable LSRs, see below) and under the | (referred to as multi-switching-type-capable LSRs, see below) and | |||
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 the | ||||
ISCs among the LSRs: | ||||
MLNs can be further categorized according to the distribution of | ||||
the ISCs among the LSRs: | ||||
- Each LSR may support just one ISC. | - Each LSR may support just one ISC. | |||
Such LSRs are known as single-switching-type-capable LSRs. The MLN | Such LSRs are known as single-switching-type-capable LSRs. | |||
may comprise a set of single-switching-type-capable LSRs some of | The MLN may comprise a set of single-switching-type-capable LSRs | |||
which support different ISCs. | some of which support different ISCs. | |||
- Each LSR may support more than one ISC at the same time. | - Each LSR may support more than one ISC at the same time. | |||
Such LSRs are known as multi-switching-type-capable LSRs, and can | - Such LSRs are known as multi-switching-type-capable LSRs, and | |||
be further classified as either "simplex" or "hybrid" nodes as | can be further classified as either "simplex" or "hybrid" nodes | |||
defined in Section 4.2. | as defined in Section 4.2. | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
- The MLN may be constructed from any combination of single- | - | |||
switching-type-capable LSRs and multi-switching-type-capable LSRs. | - - The MLN may be constructed from any combination of single- | |||
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 used | different switching capabilities, a single GMPLS instance may be | |||
to control the MLN/MRN. This enables rapid service provisioning and | used to control the MLN/MRN. This enables rapid service | |||
efficient traffic engineering across all switching capabilities. In | provisioning and efficient traffic engineering across all switching | |||
such networks, TE Links are consolidated into a single Traffic | capabilities. In such networks, TE Links are consolidated into a | |||
Engineering Database (TED). Since this TED contains the information | single Traffic Engineering Database (TED). Since this TED contains | |||
relative to all the different regions and layers existing in the | the information relative to all the different regions and layers | |||
network, a path across multiple regions or layers can be computed | existing in the network, a path across multiple regions or layers | |||
using this TED. | can be computed using this TED. Thus optimization of network | |||
resources can be achieved across the whole MLN/MRN. | ||||
Thus optimization of network resources can be achieved across the | ||||
whole MLN/MRN. Consider, for example, a MRN consisting of packet- | ||||
switch capable routers and TDM cross-connects. Assume that a packet | ||||
LSP is routed between source and destination packet-switch capable | ||||
routers, and that the LSP can be routed across the PSC-region (i.e., | ||||
utilizing only resources of the packet region topology). If the | ||||
performance objective for the packet LSP is not satisfied, new TE | ||||
links may be created between the packet-switch capable routers across | ||||
the TDM-region (for example, VC-12 links) and the LSP can be routed | ||||
over those TE links. | ||||
Furthermore, even if the LSP can be successfully established across | Consider, for example, a MRN consisting of packet- switch capable | |||
the PSC-region, TDM hierarchical LSPs across the TDM region between | routers and TDM cross-connects. Assume that a packet LSP is routed | |||
the packet-switch capable routers may be established and used if | between source and destination packet-switch capable routers, and | |||
doing so is necessary to meet the operator's objectives for network | that the LSP can be routed across the PSC-region (i.e., utilizing | |||
resources availability (e.g., link bandwidth, or adaptation ports | only resources of the packet region topology). If the performance | |||
between regions) across the regions. The same considerations hold | objective for the packet LSP is not satisfied, new TE links may be | |||
when VC4 LSPs are provisioned to provide extra flexibility for the | created between the packet-switch capable routers across the TDM- | |||
VC12 and/or VC11 layers in an MLN. | region (for example, VC-12 links) and the LSP can be routed over | |||
those TE links. Furthermore, even if the LSP can be successfully | ||||
established across the PSC-region, TDM hierarchical LSPs across the | ||||
TDM region between the packet-switch capable routers may be | ||||
established and used if doing so is necessary to meet the | ||||
operator's objectives for network resources availability (e.g., | ||||
link bandwidth.The same considerations hold when VC4 LSPs are | ||||
provisioned to provide extra flexibility for the VC12 and/or VC11 | ||||
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 applicability | specific and/or protocol elements in this document. The | |||
of existing GMPLS protocols and any protocol extensions to the | applicability of existing GMPLS protocols and any protocol | |||
MRN/MLN is addressed in separate documents [MRN-EVAL]. | extensions to the MRN/MLN is addressed in separate documents [MRN- | |||
EVAL]. | ||||
This document covers the elements of a single GMPLS control plane | This document covers the elements of a single GMPLS control plane | |||
instance controlling multiple layers within a given TE domain. A | instance controlling multiple layers within a given TE domain. A | |||
control plane instance can serve one, two or more layers. Other | control plane instance can serve one, two or more layers. Other | |||
possible approaches such as having multiple control plane instances | possible approaches such as having multiple control plane instances | |||
serving disjoint sets of layers are outside the scope of this | serving disjoint sets of layers are outside the scope of this | |||
document. It is most probable that such a MLN or MRN would be | document. It is most probable that such a MLN or MRN would be | |||
operated by a single Service Provider, but this document does not | operated by a single Service Provider, but this document does not | |||
exclude the possibility of two layers (or regions) being under | exclude the possibility of two layers (or regions) being under | |||
different administrative control (for example, by different Service | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
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 supporting | For such TE domain to interoperate with edge nodes/domains | |||
non-GMPLS interfaces (such as those defined by other SDOs), an | supporting non-GMPLS interfaces (such as those defined by other | |||
interworking function may be needed. Location and specification of | SDOs), an interworking function may be needed. Location and | |||
this function are outside the scope of this document (because | specification of this function are outside the scope of this | |||
interworking aspects are strictly under the responsibility of the | document (because interworking aspects are strictly under the | |||
interworking function). | responsibility of the interworking function). | |||
This document assumes that the interconnection of adjacent MRN/MLN TE | This document assumes that the interconnection of adjacent MRN/MLN | |||
domains makes use of [RFC4726] when their edges also support inter- | TE domains makes use of [RFC4726] when their edges also support | |||
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 "MUST", | Although this is not a protocol specification, the key words | |||
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", | |||
"RECOMMENDED", "MAY", and "OPTIONAL" are used in this document to | "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used in | |||
highlight requirements, and are to be interpreted as described in | this document to highlight requirements, and are to be interpreted | |||
RFC 2119 [RFC2119]. | as described in RFC 2119 [RFC2119]. | |||
2.1. List of Acronyms | 2.1. List of Acronyms | |||
FA: Forwarding Adjacency | FA: Forwarding Adjacency | |||
FA-LSP: Forwarding Adjacency Label Switched Path | FA-LSP: Forwarding Adjacency Label Switched Path | |||
FSC: Fiber Switching Capable | FSC: Fiber Switching Capable | |||
ISC: Interface Switching Capability | ISC: Interface Switching Capability | |||
ISCD: Interface Switching Capability Descriptor | ISCD: Interface Switching Capability Descriptor | |||
L2SC: Layer-2 Switching Capable | L2SC: Layer-2 Switching Capable | |||
LSC: Lambda Switching Capable | LSC: Lambda Switching Capable | |||
skipping to change at page 5, line 54 | skipping to change at page 7, line 4 | |||
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 | |||
multiple layers could be fully contained within a single region. For | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
example, VC12, VC4, and VC4-4c are different layers of the TDM | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
multiple layers could be fully contained within a single region. | ||||
For example, VC12, VC4, and VC4-4c are different layers of the TDM | ||||
region. | region. | |||
3.1. Data Plane Layers and Control Plane Regions | 3.1. Data Plane Layers and Control Plane Regions | |||
A data plane layer is a collection of network resources capable of | A data plane layer is a collection of network resources capable of | |||
terminating and/or switching data traffic of a particular format | terminating and/or switching data traffic of a particular format | |||
[RFC4397]. These resources can be used for establishing LSPs for | [RFC4397]. These resources can be used for establishing LSPs for | |||
traffic delivery. For example, VC-11 and VC4-64c represent two | traffic delivery. For example, VC-11 and VC4-64c represent two | |||
different layers. | different layers. | |||
From the control plane viewpoint, an LSP region is defined as a set | From the control plane viewpoint, an LSP region is defined as a set | |||
of one or more data plane layers that share the same type of | of one or more data plane layers that share the same type of | |||
switching technology, that is, the same switching type. For example, | switching technology, that is, the same switching type. For example, | |||
VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. The | VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. | |||
regions that are currently defined are: PSC, L2SC, TDM, LSC, and FSC. | The regions that are currently defined are: PSC, L2SC, TDM, LSC, | |||
Hence, an LSP region is a technology domain (identified by the ISC | and FSC. Hence, an LSP region is a technology domain (identified by | |||
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 information | represented into the control plane as an aggregate of TE | |||
associated with a set of links (i.e., TE links). For example VC-11 | information associated with a set of links (i.e., TE links). For | |||
and VC4-64c capable TE links are part of the same TDM region. | example VC-11 and VC4-64c capable TE links are part of the same TDM | |||
Multiple layers can thus exist in a single region network. | region. 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 switching | forward the signaling message between LSR hosting different | |||
technologies because change in some of the signaling objects (for | switching technologies because change in some of the signaling | |||
example, the traffic parameters) when crossing a region boundary even | objects (for example, the traffic parameters) when crossing a | |||
if a single control plane instance is used to manage the whole MRN. | region boundary even if a single control plane instance is used to | |||
We may solve this issue by using triggered signaling (see Section | manage the whole MRN. We may solve this issue by using triggered | |||
4.3.1). | signaling (see Section 4.3.1). | |||
3.2. Service Layer Networks | 3.2. Service Layer Networks | |||
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. Connectivity | highest service layer of the service provider's network. | |||
across the highest service layer of the service provider's network | Connectivity across the highest service layer of the service | |||
may be provided with support from successively lower service layers. | provider's network may be provided with support from successively | |||
Service layers are realized via a hierarchy of network layers located | lower service layers. Service layers are realized via a hierarchy | |||
generally in several regions and commonly arranged according to the | of network layers located generally in several regions and commonly | |||
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 | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
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 one | realizes the services by a stack of network layers located within | |||
or more network regions. The network layers are commonly arranged | one or more network regions. The network layers are commonly | |||
according to the switching capabilities of the devices in the | arranged according to the switching capabilities of the devices in | |||
networks. Thus, a customer network may be provided on top of the | the networks. Thus, a customer network may be provided on top of | |||
GMPLS-based multi-region/multi-layer network. For example, a Layer 1 | the GMPLS-based multi-region/multi-layer network. For example, a | |||
service (realized via the network layers of TDM, and/or LSC, and/or | Layer 1 service (realized via the network layers of TDM, and/or LSC, | |||
FSC regions) may support a Layer 2 network (realized via ATM VP/VC) | and/or FSC regions) may support a Layer 2 network (realized via ATM | |||
which may itself support a Layer 3 network (IP/MPLS region). The | VP/VC) which may itself support a Layer 3 network (IP/MPLS region). | |||
supported data plane relationship is a data plane client-server | The supported data plane relationship is a data plane client-server | |||
relationship where the lower layer provides a service for the higher | relationship where the lower layer provides a service for the | |||
layer using the data links realized in the lower layer. | 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 pure | MRN/MLN which is operated by a service provider. For example, a | |||
IP and/or an IP/MPLS network can be provided on top of GMPLS-based | pure IP and/or an IP/MPLS network can be provided on top of GMPLS- | |||
packet over optical networks [MPLS-GMPLS]. The relationship between | based packet over optical networks [MPLS-GMPLS]. The relationship | |||
the networks is a client/server relationship and, such services are | between the networks is a client/server relationship and, such | |||
referred to as "MRN/MLN services". In this case, the customer network | services are referred to as "MRN/MLN services". In this case, the | |||
may form part of the MRN/MLN, or may be partially separated, for | customer network may form part of the MRN/MLN, or may be partially | |||
example to maintain separate routing information but retain common | separated, for example to maintain separate routing information but | |||
signaling. | retain common signaling. | |||
3.3. Vertical and Horizontal Interaction and Integration | 3.3. Vertical and Horizontal Interaction and Integration | |||
Vertical interaction is defined as the collaborative mechanisms | Vertical interaction is defined as the collaborative mechanisms | |||
within a network element that is capable of supporting more than one | within a network element that is capable of supporting more than | |||
layer or region and of realizing the client/server relationships | one layer or region and of realizing the client/server | |||
between the layers or regions. Protocol exchanges between two network | relationships between the layers or regions. Protocol exchanges | |||
controllers managing different regions or layers are also a vertical | between two network controllers managing different regions or | |||
interaction. Integration of these interactions as part of the control | layers are also a vertical interaction. Integration of these | |||
plane is referred to as vertical integration. Thus, this refers to | interactions as part of the control plane is referred to as | |||
the collaborative mechanisms within a single control plane instance | vertical integration. Thus, this refers to the collaborative | |||
driving multiple network layers part of the same region or not. Such | mechanisms within a single control plane instance driving multiple | |||
a concept is useful in order to construct a framework that | network layers part of the same region or not. Such a concept is | |||
facilitates efficient network resource usage and rapid service | useful in order to construct a framework that facilitates efficient | |||
provisioning in carrier networks that are based on multiple layers, | network resource usage and rapid service provisioning in carrier | |||
switching technologies, or ISCs. | networks that are based on multiple layers, switching technologies, | |||
or ISCs. | ||||
Horizontal interaction is defined as the protocol exchange between | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
network controllers that manage transport nodes within a given layer | ||||
or region. For instance, the control plane interaction between two | ||||
TDM network elements switching at OC-48 is an example of horizontal | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
interaction. GMPLS protocol operations handle horizontal interactions | Horizontal interaction is defined as the protocol exchange between | |||
within the same routing area. The case where the interaction takes | network controllers that manage transport nodes within a given | |||
place across a domain boundary, such as between two routing areas | layer or region. For instance, the control plane interaction | |||
within the same network layer, is evaluated as part of the inter- | between two TDM network elements switching at OC-48 is an example | |||
domain work [RFC4726], and is referred to as horizontal integration. | of horizontal interaction. GMPLS protocol operations handle | |||
Thus, horizontal integration refers to the collaborative mechanisms | horizontal interactions within the same routing area. The case | |||
between network partitions and/or administrative divisions such as | where the interaction takes place across a domain boundary, such as | |||
routing areas or autonomous systems. | between two routing areas within the same network layer, is | |||
evaluated as part of the inter- domain work [RFC4726], and is | ||||
referred to as horizontal integration. Thus, horizontal integration | ||||
refers to the collaborative mechanisms between network partitions | ||||
and/or administrative divisions such as routing areas or autonomous | ||||
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 relate | mechanisms in place between two lambda switching capable areas | |||
to horizontal integration. On the other hand, the collaborative | relate to horizontal integration. On the other hand, the | |||
mechanisms in place between a packet switching capable (e.g., | collaborative mechanisms in place between a packet switching | |||
IP/MPLS) domain and a separate time division switching capable | capable (e.g., IP/MPLS) domain and a separate time division | |||
(e.g., VC4 SDH) domain over which it operates are part of the | switching capable (e.g., VC4 SDH) domain over which it operates are | |||
horizontal integration while it can also be seen as a first step | part of the horizontal integration while it can also be seen as a | |||
towards vertical integration. | first step towards 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 LSP | effective network resource utilization of both the Packet/Layer2 | |||
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 networks | The rationales for GMPLS controlled multi-layer/multi-region | |||
are summarized below: | networks 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 multiple | - The unification of the addressing spaces helps in avoiding | |||
identifiers for the same object (a link, for instance, or more | multiple identifiers for the same object (a link, for instance, | |||
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 and | requirement to maintain a dedicated routing topology per layer | |||
therefore does not mandate a full mesh of routing adjacencies as is | and therefore does not mandate a full mesh of routing adjacencies | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | as is the case with overlaid control planes. | |||
the case with overlaid control planes. | ||||
- The collaboration between technology layers where the control | - The collaboration between technology layers where the control | |||
channel is associated with the data channel (e.g. packet/framed | channel is associated with the data channel (e.g. packet/framed | |||
data planes) and technology layers where the control channel is not | data planes) and technology layers where the control channel is | |||
directly associated with the data channel (SONET/SDH, G.709, etc.) | not directly associated with the data channel (SONET/SDH, G.709, | |||
is facilitated by the capability within GMPLS to associate in-band | etc.) is facilitated by the capability within GMPLS to associate | |||
control plane signaling to the IP terminating interfaces of the | in-band control plane signaling to the IP terminating interfaces | |||
control plane. | of the control plane. | |||
- Resource management and policies to be applied at the edges of such | - Resource management and policies to be applied at the edges of | |||
a MRN/MLN is made more simple (fewer control to management | such a MRN/MLN is made more simple (fewer control to management | |||
interactions) and more scalable (through the use of aggregated | interactions) and more scalable (through the use of aggregated | |||
information). | information). | |||
- Multi-region/multi-layer traffic engineering is facilitated as | - Multi-region/multi-layer traffic engineering is facilitated as | |||
TE-links from distinct regions/layers are stored within the same TE | TE-links from distinct regions/layers are stored within the same | |||
Database. | TE Database. | |||
4. Key Concepts of GMPLS-Based MLNs and MRNs | 4. Key Concepts of GMPLS-Based MLNs and MRNs | |||
A network comprising transport nodes with multiple data plane layers | A network comprising transport nodes with multiple data plane | |||
of either the same ISC or different ISCs, controlled by a single | layers of either the same ISC or different ISCs, controlled by a | |||
GMPLS control plane instance, is called a Multi-Layer Network (MLN). | single GMPLS control plane instance, is called a Multi-Layer | |||
A sub-set of MLNs consists of networks supporting LSPs of different | Network (MLN). A sub-set of MLNs consists of networks supporting | |||
switching technologies (ISCs). A network supporting more than one | LSPs of different switching technologies (ISCs). A network | |||
switching technology is called a Multi-Region Network (MRN). | supporting more than one switching technology is called a Multi- | |||
Region Network (MRN). | ||||
4.1. Interface Switching Capability | 4.1. Interface Switching Capability | |||
The Interface Switching Capability (ISC) is introduced in GMPLS to | The Interface Switching Capability (ISC) is introduced in GMPLS to | |||
support various kinds of switching technology in a unified way | support various kinds of switching technology in a unified way | |||
[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 type) | A switching type (also referred to as the switching capability | |||
describes the ability of a node to forward data of a particular data | type) describes the ability of a node to forward data of a | |||
plane technology, and uniquely identifies a network region. The | particular data plane technology, and uniquely identifies a network | |||
following ISC types (and, hence, regions) are defined: PSC, L2SC, | region. The following ISC types (and, hence, regions) are defined: | |||
TDM, LSC, and FSC. Each end of a data link (more precisely, each | PSC, L2SC, TDM, LSC, and FSC. Each end of a data link (more | |||
interface connecting a data link to a node) in a GMPLS network is | precisely, each interface connecting a data link to a node) in a | |||
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 the | associated with a particular link interface [RFC4202]. Apart from | |||
ISC, the ISCD contains information including the encoding type, the | the ISC, the ISCD contains information including the encoding type, | |||
bandwidth granularity, and the unreserved bandwidth on each of eight | the bandwidth granularity, and the unreserved bandwidth on each of | |||
priorities at which LSPs can be established. The ISCD does not | eight priorities at which LSPs can be established. The ISCD does | |||
"identify" network layers, it uniquely characterizes information | not "identify" network layers, it uniquely characterizes | |||
associated to one or more network layers. | information associated to one or more network layers. | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 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-capable) | interpreted as advertising a multi-layer (or multi-switching- | |||
TE link end. That is, the TE link end (and therefore the TE link) is | capable) TE link end. That is, the TE link end (and therefore the | |||
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) | |||
to describe the termination capabilities of each of their TE Link(s). | to describe the termination capabilities of each of their TE | |||
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 to | "hybrid" nodes. Simplex and hybrid nodes are categorized according | |||
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 LSR | an LSR with PSC and TDM links each of which is connected to the | |||
via a separate interface. | LSR 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 the | capabilities where the data links are connected to the node by | |||
same interface. So, it advertises a single TE Link containing more | the same interface. So, it advertises a single TE Link | |||
than one ISCD each with a different ISC value. For example, a node | containing more than one ISCD each with a different ISC value. | |||
may terminate PSC and TDM data links and interconnect those | For example, a node may terminate PSC and TDM data links and | |||
external data links via internal links. The external interfaces | interconnect those external data links via internal links. The | |||
connected to the node have both PSC and TDM capabilities. | external interfaces connected to the node have both PSC and TDM | |||
capabilities. | ||||
Additionally, TE link advertisements issued by a simplex or a hybrid | Additionally, TE link advertisements issued by a simplex or a | |||
node may need to provide information about the node's internal | hybrid node may need to provide information about the node's | |||
adaptation capabilities between the switching technologies supported. | internal adjustment capacity between the switching technologies | |||
That is, the node's capability to perform layer border node | supported. The term "adjustment" capacity refers to the property of | |||
functions. This information allows path computation to select an end- | an hybrid node to interconnect different switching capabilities it | |||
to-end multi-layer or multi-region path that includes links of | provides through its external interfaces.. This information allows | |||
different switching capabilities that are joined by LSRs that can | path computation to select an end- to-end multi-layer or multi- | |||
adapt the signal between the links. | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes | region path that includes links of different switching capabilities | |||
that are joined by LSRs that can adapt the signal between the links. | ||||
This type of network contains at least one hybrid node, zero or more | 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes | |||
simplex nodes, and a set of single-switching-type-capable nodes. | This type of network contains at least one hybrid node, zero or | |||
more 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 link | PSC switching respectively. The node terminates a PSC and a TDM | |||
(Link1 and Link2 respectively). It also has an internal link | link (Link1 and Link2 respectively). It also has an internal link | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
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 adaptation 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 connecting | PSC interface (#b). This situation is modeled in GMPLS by | |||
the local end of Link2 to the TDM switching element via an additional | connecting the local end of Link2 to the TDM switching element via | |||
interface realizing the termination/adaptation function. There are | an additional interface realizing the termination/adjustment | |||
two possible ways to set up PSC LSPs through the hybrid node. | function. There are two possible ways to set up PSC LSPs through | |||
Available resource advertisement (i.e., Unreserved and Min/Max LSP | the hybrid node. Available resource advertisement (i.e., Unreserved | |||
Bandwidth) should cover both of these methods. | and Min/Max LSP Bandwidth) should cover both of these methods. | |||
Network element | Network element | |||
............................. | ............................. | |||
: -------- : | : -------- : | |||
: | PSC | : | : | PSC | : | |||
Link1 -------------<->--|#a | : | Link1 -------------<->--|#a | : | |||
: | | : | : | | : | |||
: +--<->---|#b | : | : +--<->---|#b | : | |||
: | -------- : | : | -------- : | |||
: | ---------- : | : | ---------- : | |||
skipping to change at page 11, line 38 | skipping to change at page 12, line 50 | |||
+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 use | consolidated into a single Traffic Engineering Database (TED) for | |||
by the single control plane instance. Since this TED contains the | use by the single control plane instance. Since this TED contains | |||
information relative to all the layers of all regions in the network, | the information relative to all the layers of all regions in the | |||
a path across multiple layers (possibly crossing multiple regions) | network, a path across multiple layers (possibly crossing multiple | |||
can be computed using the information in this TED. Thus, optimization | regions) can be computed using the information in this TED. Thus, | |||
of network resources across the multiple layers of the same region | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
and across multiple regions can be achieved. | ||||
These concepts allow for the operation of one network layer over the | optimization of network resources across the multiple layers of the | |||
topology (that is, TE links) provided by other network layers (for | same region and across multiple regions can be achieved. | |||
example, the use of a lower layer LSC LSP carrying PSC LSPs). In | ||||
turn, a greater degree of control and inter-working can be achieved, | These concepts allow for the operation of one network layer over | |||
including (but not limited too): | the topology (that is, TE links) provided by other network layers | |||
(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 | ||||
achieved, including (but not limited too): | ||||
- Dynamic establishment of Forwarding Adjacency (FA) LSPs | - Dynamic establishment of Forwarding Adjacency (FA) LSPs | |||
[RFC4206] (see Sections 4.3.2 and 4.3.3). | [RFC4206] (see Sections 4.3.2 and 4.3.3). | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
- Provisioning of end-to-end LSPs with dynamic triggering of FA | - Provisioning of end-to-end LSPs with dynamic triggering of FA | |||
LSPs. | LSPs. | |||
Note that in a multi-layer/multi-region network that includes multi- | Note that in a multi-layer/multi-region network that includes | |||
switching-type-capable nodes, an explicit route used to establish an | multi- switching-type-capable nodes, an explicit route used to | |||
end-to-end LSP can specify nodes that belong to different layers or | establish an end-to-end LSP can specify nodes that belong to | |||
regions. In this case, a mechanism to control the dynamic creation of | different layers or regions. In this case, a mechanism to control | |||
FA-LSPs may be required (see Sections 4.3.2 and 4.3.3). | 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 of | dynamically established. The process can be subject to the control | |||
a policy, which may be set by a management component, and which may | of a policy, which may be set by a management component, and which | |||
require that the management plane is consulted at the time that the | may require that the management plane is consulted at the time that | |||
FA-LSP is established. Alternatively, the FA-LSP can be established | the FA-LSP is established. Alternatively, the FA-LSP can be | |||
at the request of the control plane without any management control. | established at the request of the control plane without any | |||
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 layer. | may be nested into a lower layer FA-LSP that crosses the lower | |||
From a signaling perspective, there are two alternatives to establish | layer. From a signaling perspective, there are two alternatives to | |||
the lower layer FA-LSP: static (pre-provisioned) and dynamic | establish the lower layer FA-LSP: static (pre-provisioned) and | |||
(triggered). A pre-provisioned FA-LSP may be initiated either by the | dynamic (triggered). A pre-provisioned FA-LSP may be initiated | |||
operator or automatically using features like TE auto-mesh | either by the operator or automatically using features like TE | |||
[RFC4972]. If such a lower layer LSP does not already exist, the LSP | auto-mesh [RFC4972]. If such a lower layer LSP does not already | |||
may be established dynamically. Such a mechanism is referred to as | exist, the LSP may be established dynamically. Such a mechanism is | |||
"triggered signaling". | referred to as "triggered signaling". | |||
4.3.2. FA-LSPs | 4.3.2. FA-LSPs | |||
Once an LSP is created across a layer from one layer border node to | Once an LSP is created across a layer from one layer border node | |||
another, it can be used as a data link in an upper layer. | to 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 link | LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE | |||
is called a Forwarding Adjacency (FA). An FA has the special | link is called a Forwarding Adjacency (FA). An FA has the special | |||
characteristic of not requiring a routing adjacency (peering) between | characteristic of not requiring a routing adjacency (peering) | |||
its end points yet still guaranteeing control plane connectivity | between its end points yet still guaranteeing control plane | |||
between the FA-LSP end points based on a signaling adjacency. An FA | connectivity between the FA-LSP end points based on a signaling | |||
is a useful and powerful tool for improving the scalability of GMPLS | adjacency. An FA is a useful and powerful tool for improving the | |||
Traffic Engineering (TE) capable networks since multiple higher layer | scalability of GMPLS Traffic Engineering (TE) capable networks | |||
LSPs may be nested (aggregated) over a single FA-LSP. | since multiple higher layer LSPs may be nested (aggregated) over a | |||
single FA-LSP. | ||||
The aggregation of LSPs enables the creation of a vertical (nested) | The aggregation of LSPs enables the creation of a vertical (nested) | |||
LSP Hierarchy. A set of FA-LSPs across or within a lower layer can be | LSP Hierarchy. A set of FA-LSPs across or within a lower layer can | |||
used during path selection by a higher layer LSP. Likewise, the | be used during path selection by a higher layer LSP. Likewise, the | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
higher layer LSPs may be carried over dynamic data links realized via | higher layer LSPs may be carried over dynamic data links realized | |||
LSPs (just as they are carried over any "regular" static data links). | via LSPs (just as they are carried over any "regular" static data | |||
This process requires the nesting of LSPs through a hierarchical | links). This process requires the nesting of LSPs through a | |||
process [RFC4206]. The TED contains a set of LSP advertisements from | hierarchical process [RFC4206]. The TED contains a set of LSP | |||
different layers that are identified by the ISCD contained within the | advertisements from different layers that are identified by the | |||
TE link advertisement associated with the LSP [RFC4202]. | 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 used | If a lower layer LSP is not advertised as an FA, it can still be | |||
to carry higher layer LSPs across the lower layer. For example, if | used to carry higher layer LSPs across the lower layer. For example, | |||
the LSP is set up using triggered signaling, it will be used to carry | if the LSP is set up using triggered signaling, it will be used to | |||
the higher layer LSP that caused the trigger. Further, the lower | carry the higher layer LSP that caused the trigger. Further, the | |||
layer remains available for use by other higher layer LSPs arriving | lower layer remains available for use by other higher layer LSPs | |||
at the boundary. | arriving 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-layers. | words, provides a virtual network topology (VNT) to the upper- | |||
For instance, a set of LSPs, each of which is supported by an LSC | layers. For instance, a set of LSPs, each of which is supported by | |||
LSP, provides a virtual network topology to the layers of a PSC | an LSC LSP, provides a virtual network topology to the layers of a | |||
region, assuming that the PSC region is connected to the LSC region. | PSC region, assuming that the PSC region is connected to the LSC | |||
Note that a single lower-layer LSP is a special case of the VNT. The | region. Note that a single lower-layer LSP is a special case of the | |||
virtual network topology is configured by setting up or tearing down | VNT. The virtual network topology is configured by setting up or | |||
the lower layer LSPs. By using GMPLS signaling and routing protocols, | tearing down the lower layer LSPs. By using GMPLS signaling and | |||
the virtual network topology can be adapted to traffic demands. | routing protocols, the virtual network topology can be adapted to | |||
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 important | However, hiding the routes of the lower-layer LSPs may lose | |||
information that is needed to make the higher-layer LSPs reliable. | important information that is needed to make the higher-layer LSPs | |||
For instance, the routing and traffic engineering in the IP/MPLS | reliable. For instance, the routing and traffic engineering in the | |||
layer does not usually consider how the IP/MPLS TE links are formed | IP/MPLS layer does not usually consider how the IP/MPLS TE links | |||
from optical paths that are routed in the fiber layer. Two optical | are formed from optical paths that are routed in the fiber layer. | |||
paths may share the same fiber link in the lower-layer and therefore | Two optical paths may share the same fiber link in the lower-layer | |||
they may both fail if the fiber link is cut. Thus the shared risk | and therefore they may both fail if the fiber link is cut. Thus the | |||
properties of the TE links in the VNT must be made available to the | shared risk properties of the TE links in the VNT must be made | |||
higher layer during path computation. Further, the topology of the | available to the higher layer during path computation. Further, the | |||
VNT should be designed so that any single fiber cut does not bisect | topology of the VNT should be designed so that any single fiber cut | |||
the VNT. These issues are addressed later in this document. | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
does not bisect the VNT. These issues are addressed later in this | ||||
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 | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | requests from the upper layer, and network failures. For instance, | |||
by reconfiguring the virtual network topology according to the | ||||
requests from the upper layer, and network failures. For instance, by | traffic demand between source and destination node pairs, network | |||
reconfiguring the virtual network topology according to the traffic | performance factors, such as maximum link utilization and residual | |||
demand between source and destination node pairs, network performance | capacity of the network, can be optimized. Reconfiguration is | |||
factors, such as maximum link utilization and residual capacity of | performed by computing the new VNT from the traffic demand matrix | |||
the network, can be optimized. Reconfiguration is performed by | and optionally from the current VNT. Exact details are outside the | |||
computing the new VNT from the traffic demand matrix and optionally | scope of this document. However, this method may be tailored | |||
from the current VNT. Exact details are outside the scope of this | according to the service provider's policy regarding network | |||
document. However, this method may be tailored according to the | performance and quality of service (delay, loss/disruption, | |||
service provider's policy regarding network performance and quality | utilization, residual capacity, reliability). | |||
of service (delay, loss/disruption, 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 | ||||
The MRN/MLN can consist of single-switching-type-capable and multi- | multi- switching-type-capable nodes. The path computation mechanism | |||
switching-type-capable nodes. The path computation mechanism in the | in the MLN SHOULD be able to compute paths consisting of any | |||
MLN SHOULD be able to compute paths consisting of any combination of | combination of such nodes. | |||
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 Adaptation 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 advertise | links required for vertical (layer) integration) and SHOULD | |||
the resource information for those links. Likewise, path computation | advertise the resource information for those links. Likewise, path | |||
elements SHOULD be prepared to use the availability of termination/ | computation elements SHOULD be prepared to use the availability of | |||
adaptation resources as a constraint in MRN/MLN path computations to | termination/ adjustment resources as a constraint in MRN/MLN path | |||
reduce the higher layer LSP setup blocking probability caused by the | computations to reduce the higher layer LSP setup blocking | |||
lack of necessary termination/adaptation resources in the lower | probability caused by the lack of necessary termination/adjustment | |||
layer(s). | resources in the lower layer(s). | |||
The advertisement of the adaptation 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, as | lower-region and forward traffic in the upper-region is REQUIRED, | |||
it provides critical information when performing multi-region path | as it provides critical information when performing multi-region | |||
computation. | path computation. | |||
The mechanism SHOULD cover the case where the upper-layer links which | The mechanism SHOULD cover the case where the upper-layer links | |||
are directly connected to upper-layer switching element and the ones | which are directly connected to upper-layer switching element and | |||
which are connected through internal links between upper-layer | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
element and lower-layer element coexist (see Section 4.2.1). | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | the ones which are connected through internal links between upper- | |||
layer element and lower-layer element coexist (see Section 4.2.1). | ||||
5.3. Scalability | 5.3. Scalability | |||
The MRN/MLN relies on unified routing and traffic engineering | The MRN/MLN relies on unified routing and traffic engineering | |||
models. | models. | |||
- Unified routing model: By maintaining a single routing protocol | - Unified routing model: By maintaining a single routing protocol | |||
instance and a single TE database per LSR, a unified control plane | instance and a single TE database per LSR, a unified control | |||
model removes the requirement to maintain a dedicated routing | plane model removes the requirement to maintain a dedicated | |||
topology per layer, and therefore does not mandate a full mesh of | routing topology per layer, and therefore does not mandate a | |||
routing adjacencies per layer. | full mesh of routing adjacencies per layer. | |||
- Unified TE model: The TED in each LSR is populated with TE-links | - Unified TE model: The TED in each LSR is populated with TE-links | |||
from all layers of all regions (TE link interfaces on multiple- | from all layers of all regions (TE link interfaces on multiple- | |||
switching-capability LSRs can be advertised with multiple ISCDs). | switching-capability LSRs can be advertised with multiple ISCDs). | |||
This may lead to an increase in the amount of information that has | This may lead to an increase in the amount of information that | |||
to be flooded and stored within the network. | has to be flooded and stored within the network. | |||
Furthermore, path computation times, which may be of great importance | Furthermore, path computation times, which may be of great | |||
during restoration, will depend on the size of the TED. | importance 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 LSPs - Number of regions and layers | |||
- 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 mechanism | information filtering based on ISCDs. The path computation | |||
and the signaling protocol SHOULD be able to operate on partial TE | mechanism and the signaling protocol SHOULD be able to operate on | |||
information. | partial TE 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 VNT | |||
(Virtual Network Topologies). The introduction of virtual topological | (Virtual Network Topologies). The introduction of virtual | |||
maps leads us to consider the concept of emulation of data plane | topological maps leads us to consider the concept of emulation of | |||
overlays. | data plane overlays. | |||
5.4. Stability | 5.4. Stability | |||
Path computation is dependent on the network topology and associated | Path computation is dependent on the network topology and | |||
link state. The path computation stability of an upper layer may be | associated link state. The path computation stability of an upper | |||
impaired if the VNT changes frequently and/or if the status and TE | layer may be impaired if the VNT changes frequently and/or if the | |||
parameters (the TE metric, for instance) of links in the VNT changes | status and TE parameters (the TE metric, for instance) of links in | |||
frequently. In this context, robustness of the VNT is defined as the | the VNT changes frequently. In this context, robustness of the VNT | |||
capability to smooth changes that may occur and avoid their | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
propagation into higher layers. Changes to the VNT may be caused by | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
the creation, deletion, or modification of LSPs. | is defined as the 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. | ||||
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 demand | adjacent layers or through operational actions to meet traffic | |||
changes, topology changes, signaling requests from the upper layer, | demand changes, topology changes, signaling requests from the upper | |||
and network failures. Routing robustness SHOULD be traded with | layer, and network failures. Routing robustness SHOULD be traded | |||
adaptability with respect to the change of incoming traffic requests. | with adaptability with respect to the change of incoming traffic | |||
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 upper | the upper-layer LSP might be disrupted. Such disruption to the | |||
layers MUST be minimized. | upper layers MUST be minimized. | |||
When residual resource decreases to a certain level, some lower layer | When residual resource decreases to a certain level, some lower | |||
LSPs MAY be released according to local or network policies. There is | layer LSPs MAY be released according to local or network policies. | |||
a trade-off between minimizing the amount of resource reserved in the | There is a trade-off between minimizing the amount of resource | |||
lower layer and disrupting higher layer traffic (i.e. moving the | reserved in the lower layer and disrupting higher layer traffic | |||
traffic to other TE-LSPs so that some LSPs can be released). Such | (i.e. moving the traffic to other TE-LSPs so that some LSPs can be | |||
traffic disruption MAY be allowed, but MUST be under the control of | released). Such traffic disruption MAY be allowed, but MUST be | |||
policy that can be configured by the operator. Any repositioning of | under the control of policy that can be configured by the operator. | |||
traffic MUST be as non-disruptive as possible (for example, using | Any repositioning of traffic MUST be as non-disruptive as possible | |||
make-before-break). | (for example, using make-before-break). | |||
5.6. LSP Attribute Inheritance | 5.6. LSP Attribute Inheritance | |||
TE-Link parameters SHOULD be inherited from the parameters of the LSP | TE-Link parameters SHOULD be inherited from the parameters of the | |||
that provides the TE-link, and so from the TE-links in the lower | LSP that provides the TE-link, and so from the TE-links in the | |||
layer that are traversed by the LSP. | lower 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 metric | Particular attention should be given to the inheritance of TE | |||
(which may be other than a strict sum of the metrics of the component | metric (which may be other than a strict sum of the metrics of the | |||
TE links at the lower layer), protection attributes, and SRLG. | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
As described earlier, hiding the routes of the lower-layer LSPs may | component TE links at the lower layer), protection attributes, and | |||
lose important information necessary to make LSPs in the higher layer | SRLG. | |||
network reliable. SRLGs may be used to identify which lower-layer | ||||
LSPs share the same failure risk so that the potential risk of the | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
VNT becoming disjoint can be minimized, and so that resource disjoint | As described earlier, hiding the routes of the lower-layer LSPs may | |||
protection paths can be set up in the higher layer. How to inherit | lose important information necessary to make LSPs in the higher | |||
the SRLG information from the lower layer to the upper layer needs | layer network reliable. SRLGs may be used to identify which lower- | |||
more discussion and is out of scope of this document. | layer LSPs share the same failure risk so that the potential risk | |||
of the VNT becoming disjoint can be minimized, and so that resource | ||||
disjoint protection paths can be set up in the higher layer. How to | ||||
inherit 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 both | for the LSP, the TED MAY be filtered to include only links where | |||
end include requested LSP switching type. In this way hierarchical | both end include requested LSP switching type. In this way | |||
routing is done by using a TED filtered with respect to switching | hierarchical routing is done by using a TED filtered with respect | |||
capability (that is, with respect to particular layer). | to switching capability (that is, with respect to particular layer). | |||
If triggered signaling is allowed, the path computation mechanism MAY | If triggered signaling is allowed, the path computation mechanism | |||
produce a route containing multiple layers/regions. The path is | MAY produce a route containing multiple layers/regions. The path is | |||
computed over the multiple layers/regions even if the path is not | computed over the multiple layers/regions even if the path is not | |||
"connected" in the same layer as the endpoints of the path exist. | "connected" in the same layer as the endpoints of the path exist. | |||
Note that here we assume that triggered signaling will be invoked to | Note that here we assume that triggered signaling will be invoked | |||
make the path "connected", when the upper-layer signaling request | to make the path "connected", when the upper-layer signaling | |||
arrives at the boundary node. | request arrives at the boundary node. | |||
The upper-layer signaling request may contain an ERO that includes | The upper-layer signaling request may contain an ERO 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 a | responsible for triggered creation of the lower-layer FA-LSP using | |||
path of its choice, or for the selection of any available lower layer | a path of its choice, or for the selection of any available lower | |||
LSP as a data link for the higher layer. This mechanism is | layer LSP as a data link for the higher layer. This mechanism is | |||
appropriate for environments where the TED is filtered in the higher | appropriate for environments where the TED is filtered in the | |||
layer, where separate routing instances are used per layer, or where | higher layer, where separate routing instances are used per layer, | |||
administrative policies prevent the higher layer from specifying | or where administrative policies prevent the higher layer from | |||
paths through the lower layer. | specifying paths through the lower layer. | |||
Obviously, if the lower layer LSP has been advertised as a TE link | Obviously, if the lower layer LSP has been advertised as a TE link | |||
(virtual or real) into the higher layer, then the higher layer | (virtual or real) into the higher layer, then the higher layer | |||
signaling request may contain the TE link identifier and so indicate | signaling request may contain the TE link identifier and so | |||
the lower layer resources to be used. But in this case, the path of | indicate the lower layer resources to be used. But in this case, | |||
the lower layer LSP can be dynamically changed by the lower layer at | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
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. | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
Even in case the lower-layer FA-LSPs are already established, a | Even in case the lower-layer FA-LSPs are already established, a | |||
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 should | situation, it is up to the boundary node to decide whether it | |||
a new lower-layer FA-LSP or it should use the existing lower-layer | should a new lower-layer FA-LSP or it should use the existing | |||
FA-LSPs. | lower-layer FA-LSPs. | |||
The lower-layer FA-LSP can be advertised just as an FA-LSP in the | The lower-layer FA-LSP can be advertised just as an FA-LSP in the | |||
upper-layer or an IGP adjacency can be brought up on the lower-layer | upper-layer or an IGP adjacency can be brought up on the lower- | |||
FA-LSP. | layer 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 the | reservable bandwidth of the TE link (FA-LSP) that carries it. On | |||
other hand, a TDM, or LSC LSP always consumes a fixed amount of | the 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, the | fraction of the available bandwidth of an FA-LSP is still in use, | |||
nested LSPs can also be re-routed to other FA-LSPs (optionally using | the nested LSPs can also be re-routed to other FA-LSPs (optionally | |||
the make-before-break technique) to completely free up the FA-LSP. | using the make-before-break technique) to completely free up the | |||
Alternatively, unused FA-LSPs MAY be retained for future use. Release | FA-LSP. Alternatively, unused FA-LSPs MAY be retained for future | |||
or retention of underutilized FA-LSPs is a policy decision. | use. Release or retention of underutilized FA-LSPs is a policy | |||
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 such | the region. By creating the new FA-LSPs, the network performance | |||
as maximum residual capacity may increase. | such as maximum residual capacity may increase. | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 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 to | In this case, re-optimization of FA-LSPs MAY be invoked according | |||
policy. | to policy. | |||
Any solution MUST include measures to protect against network | Any solution MUST include measures to protect against network | |||
destabilization caused by the rapid setup and teardown of LSPs as | destabilization caused by the rapid setup and teardown of LSPs as | |||
traffic demand varies near a threshold. | traffic demand varies near a threshold. | |||
Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly | Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly | |||
advertise the LSP as a TE link and to coordinate into which routing | advertise the LSP as a TE link and to coordinate into which routing | |||
instances the TE link should be advertised. | instances the TE link should be advertised. | |||
5.8.2. Virtual TE-Links | 5.8.2. Virtual TE-Links | |||
It may be considered disadvantageous to fully instantiate (i.e. pre- | It may be considered disadvantageous to fully instantiate (i.e. | |||
provision) the set of lower layer LSPs that provide the VNT since | pre- provision) the set of lower layer LSPs that provide the VNT | |||
this might reserve bandwidth that could be used for other LSPs in the | since this might reserve bandwidth that could be used for other | |||
absence of upper-layer traffic. | LSPs in the absence of upper-layer traffic. | |||
However, in order to allow path computation of upper-layer LSPs | However, in order to allow path computation of upper-layer LSPs | |||
across the lower-layer, the lower-layer LSPs MAY be advertised into | across the lower-layer, the lower-layer LSPs MAY be advertised into | |||
the upper-layer as though they had been fully established, but | the upper-layer as though they had been fully established, but | |||
without actually establishing them. Such TE links that represent the | without actually establishing them. Such TE links that represent | |||
possibility of an underlying LSP are termed "virtual TE-links." It is | the possibility of an underlying LSP are termed "virtual TE-links." | |||
an implementation choice at a layer boundary node whether to create | It is an implementation choice at a layer boundary node whether to | |||
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 lower | higher layer, it is possible to route a higher layer LSP into a | |||
layer on the assumptions that proper hierarchical LSPs in the lower | lower layer on the assumptions that proper hierarchical LSPs in the | |||
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-computed | TE-links across the upper-layer can remain stable using pre- | |||
paths while wastage of bandwidth within the lower-layer and | computed paths while wastage of bandwidth within the lower-layer | |||
unnecessary reservation of adaptation ports at the border nodes can | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
be avoided. | ||||
The solution SHOULD provide operations to facilitate the build-up of | and unnecessary reservation of adaptation resource at the border | |||
such virtual TE-links, taking into account the (forecast) traffic | nodes can be avoided. | |||
demand and available resource in the lower-layer. | ||||
The solution SHOULD provide operations to facilitate the build-up | ||||
of such virtual TE-links, taking into account the (forecast) | ||||
traffic 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-05.txt August 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-links | The concept of the VNT can be extended to allow the virtual TE- | |||
to form part of the VNT. The combination of the fully provisioned TE- | links to form part of the VNT. The combination of the fully | |||
links and the virtual TE-links defines the VNT provided by the lower | provisioned TE- links and the virtual TE-links defines the VNT | |||
layer. The VNT can be changed by setting up and/or tearing down | provided by the lower layer. The VNT can be changed by setting up | |||
virtual TE links as well as by modifying real links (i.e., the fully | and/or tearing down virtual TE links as well as by modifying real | |||
provisioned LSPs). How to design the VNT and how to manage it are out | links (i.e., the fully provisioned LSPs). How to design the VNT and | |||
of scope of this document. | how to manage it are out of scope of this document. | |||
In some situations, selective advertisement of the preferred | ||||
connectivity among a set of border nodes between layers may be | ||||
appropriate. Further decreasing the number of advertisement of the | ||||
virtual connectivity can be achieved by abstracting the topology | ||||
(between border nodes) using models similar to those detailed in | ||||
[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 are | data integrity. Such mechanisms are data technology-specific and | |||
beyond the scope of this document, but may be coordinated through the | are beyond the scope of this document, but may be coordinated | |||
GMPLS control plane. | through the 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 operated | However, where the separate layers of a MLN/MRN network are | |||
as different administrative domains, additional security | operated 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-off | information shared between administrative domains, and the trade- | |||
between multi-layer TE and confidentiality of information belonging | off between multi-layer TE and confidentiality of information | |||
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. | |||
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 of | The authors would like to thank Adrian Farrel and the participants | |||
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-05.txt August 2007 | 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. | |||
[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 | [RFC4726] Farrel, A., Vasseur, JP., and Ayyangar, A., "A | |||
for Inter-Domain Multiprotocol Label Switching Traffic | Framework for Inter-Domain Multiprotocol Label | |||
Engineering", RFC 4726, November 2006. | Switching Traffic Engineering", RFC 4726, November 2006. | |||
[RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) | [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths | |||
Hierarchy with Generalized Multi-Protocol Label Switching | (LSP) Hierarchy with Generalized Multi-Protocol Label | |||
(GMPLS) Traffic Engineering (TE)," RFC4206, Oct. 2005. | Switching (GMPLS) Traffic Engineering (TE)," RFC4206, | |||
Oct. 2005. | ||||
[RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label | [RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Architecture", RFC 3945, October 2004. | Switching (GMPLS) Architecture", RFC 3945, October 2004. | |||
[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 Switching | Interpretation of Generalized Multiprotocol Label | |||
(GMPLS) Terminology within the Context of the ITU-T's | Switching (GMPLS) Terminology within the Context of the | |||
Automatically Switched Optical Network (ASON) | ITU-T's Automatically Switched Optical Network (ASON) | |||
Architecture", RFC 4397, February 2006. | Architecture", RFC 4397, February 2006. | |||
9.2. Informative References | 9.2. Informative References | |||
[MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., | [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, | |||
Shiomoto, K., Vigoureux, M., "Evaluation of Existing | D., Shiomoto, K., Vigoureux, M., "Evaluation of | |||
GMPLS Protocols Against Multi-Layer and Multi-Region | Existing GMPLS Protocols Against Multi-Layer and | |||
Network (MLN/MRN) Requirements", draft-ietf-ccamp-gmpls- | Multi-Region Network (MLN/MRN) Requirements", draft- | |||
mln-eval, work in progress. | ietf-ccamp-gmpls- mln-eval, work in progress. | |||
[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. | ||||
[DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and | and Ali, Z., "Procedures for Dynamically Signaled | |||
Ali, Z., "Procedures for Dynamically Signaled | ||||
Hierarchical Label Switched Paths", draft-ietf-ccamp- | Hierarchical Label Switched Paths", draft-ietf-ccamp- | |||
lsp-hierarchy-bis, work in progress. | lsp-hierarchy-bis, work in progress. | |||
[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", draft-fang-mpls-gmpls-security- | |||
framework, work in progress. | framework, work in progress. | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | |||
[RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing Extensions | [RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing | |||
for Discovery of Multiprotocol (MPLS) Label Switch | Extensions for Discovery of Multiprotocol (MPLS) | |||
Router (LSR) Traffic Engineering (TE) Mesh Membership", | Label Switch Router (LSR) Traffic Engineering (TE) | |||
RFC 4972, July 2007. | Mesh Membership", RFC 4972, 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, | 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan | |||
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 | |||
skipping to change at page 22, line 50 | skipping to change at page 25, line 52 | |||
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 | |||
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, | 3-9-11 Midori-cho, Musashino-shi, | |||
Musashino-shi, | ||||
Tokyo 180-8585, | Tokyo 180-8585, | |||
draft-ietf-ccamp-gmpls-mln-reqs-06.txt October 2007 | ||||
Japan | 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 | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
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 | |||
skipping to change at page 23, line 26 | skipping to change at page 26, line 30 | |||
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 to | Intellectual Property Rights or other rights that might be claimed | |||
pertain to the implementation or use of the technology described in | to pertain to the implementation or use of the technology described | |||
this document or the extent to which any license under such rights | in this document or the extent to which any license under such | |||
might or might not be available; nor does it represent that it has | rights might or might not be available; nor does it represent that | |||
made any independent effort to identify any such rights. Information | it has made any independent effort to identify any such rights. | |||
on the procedures with respect to rights in RFC documents can be | Information on the procedures with respect to rights in RFC | |||
found in BCP 78 and BCP 79. | documents can be found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use | |||
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 at | specification can be obtained from the IETF on-line IPR repository | |||
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 | this standard. Please address the information to the IETF at ietf- | |||
ietf-ipr@ietf.org. | ipr@ietf.org. | |||
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. | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | This document and the information contained herein are provided on | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | ||||
This document and the information contained herein are provided on an | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST | WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY | |||
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | |||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS | |||
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY | FOR A PARTICULAR PURPOSE. | |||
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR | ||||
PURPOSE. | ||||
End of changes. 143 change blocks. | ||||
590 lines changed or deleted | 612 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/ |