draft-ietf-ccamp-gmpls-mln-reqs-04.txt | draft-ietf-ccamp-gmpls-mln-reqs-05.txt | |||
---|---|---|---|---|
skipping to change at page 1, line 14 | skipping to change at page 1, line 14 | |||
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: February 2008 August 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-04.txt | draft-ietf-ccamp-gmpls-mln-reqs-05.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any applicable | By submitting this Internet-Draft, each author represents that any | |||
patent or other IPR claims of which he or she is aware have been or will be | applicable patent or other IPR claims of which he or she is aware | |||
disclosed, and any of which he or she becomes aware will be disclosed, in | have been or will be disclosed, and any of which he or she becomes | |||
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 Task Force | Internet-Drafts are working documents of the Internet Engineering | |||
(IETF), its areas, and its working groups. Note that other groups may also | Task Force (IETF), its areas, and its working groups. Note that | |||
distribute working documents as Internet-Drafts. | other groups may also distribute working documents as Internet- | |||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months and may be | Internet-Drafts are draft documents valid for a maximum of six months | |||
updated, replaced, or obsoleted by other documents at any time. It is | and may be updated, replaced, or obsoleted by other documents at any | |||
inappropriate to use Internet-Drafts as reference material or to cite them other | time. It is inappropriate to use Internet-Drafts as reference | |||
than as "work in progress." | 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 on Februrary 2008. | This Internet-Draft will expire in February 2008. | |||
Copyright Notice | ||||
Copyright (C) The IETF Trust (2007). | ||||
Abstract | Abstract | |||
Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been | Most of the initial efforts to utilize Generalized MPLS (GMPLS) have | |||
related to environments hosting devices with a single switching capability. The | been related to environments hosting devices with a single switching | |||
complexity raised by the control of such data planes is similar to that seen in | capability. The complexity raised by the control of such data planes | |||
classical IP/MPLS networks. | is similar to that seen in classical IP/MPLS networks. | |||
By extending MPLS to support multiple switching technologies, GMPLS provides a | By extending MPLS to support multiple switching technologies, GMPLS | |||
comprehensive framework for the control of a multi-layered network of either a | provides a comprehensive framework for the control of a multi-layered | |||
single switching technology or multiple switching technologies. | network of either a single switching technology or multiple switching | |||
technologies. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
In GMPLS, a switching technology domain defines a region, and a network of | In GMPLS, a switching technology domain defines a region, and a | |||
multiple switching types is referred to in this document as a Multi-Region | network of multiple switching types is referred to in this document | |||
Network (MRN). When referring in general to a layered network, which may consist | as a Multi-Region Network (MRN). When referring in general to a | |||
of either a single or multiple regions, this document uses the term, Multi-Layer | layered network, which may consist of either a single or multiple | |||
Network (MLN). This document defines a framework for GMPLS based multi- | regions, this document uses the term, Multi-Layer Network (MLN). This | |||
region/multi-layer networks and lists a set of functional requirements. | document defines a framework for GMPLS based multi-region/multi-layer | |||
networks and lists a set of functional requirements. | ||||
Table of Contents | Table of Contents | |||
1. Introduction.....................................................2 | 1. Introduction .................................................... | |||
2. Conventions Used in this Document....................................4 | 1.1. Scope ......................................................... | |||
2.1. List of acronyms................................................4 | 2. Conventions Used in this Document ............................... | |||
3. Positioning......................................................5 | 2.1. List of Acronyms .............................................. | |||
3.1. Data Plane Layers and Control Plane Regions..........................5 | 3. Positioning ..................................................... | |||
3.2. Service layer networks...........................................6 | 3.1. Data Plane Layers and Control Plane Regions ................... | |||
3.3. Vertical and Horizontal interaction and integration...................6 | 3.2. Service Layer Networks .. ..................................... | |||
4. Key Concepts of GMPLS-Based MLNs and MRNs.............................8 | 3.3. Vertical and Horizontal Interaction and Integration ........... | |||
4.1. Interface Switching Capability....................................8 | 3.4. Motivation .................................................... | |||
4.2. Multiple Interface Switching Capabilities...........................8 | 4. Key Concepts of GMPLS-Based MLNs and MRNs ....................... | |||
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes..............9 | 4.1. Interface Switching Capability ................................ | |||
4.3. Integrated Traffic Engineering (TE) and Resource Control..............10 | 4.2. Multiple Interface Switching Capabilities ..................... | |||
4.3.1. Triggered Signaling...........................................10 | 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes ..... | |||
4.3.2. FA-LSPs.....................................................11 | 4.3. Integrated Traffic Engineering (TE) and Resource Control ...... | |||
4.3.3. Virtual Network Topology (VNT)..................................11 | 4.3.1. Triggered Signaling ......................................... | |||
5. Requirements....................................................12 | 4.3.2. FA-LSPs ..................................................... | |||
5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes.......12 | 4.3.3. Virtual Network Topology (VNT) .............................. | |||
5.2. Advertisement of the Available Adaptation Resource...................12 | 5. Requirements .................................................... | |||
5.3. Scalability...................................................13 | 5.1. Handling Single-Switching and Multi-Switching-Type-Capable | |||
5.4. Stability.....................................................13 | Nodes ....................................................... | |||
5.5. Disruption Minimization.........................................14 | 5.2. Advertisement of the Available Adaptation Resource ............ | |||
5.6. LSP Attribute Inheritance........................................14 | 5.3. Scalability ................................................... | |||
5.7. Computing Paths With and Without Nested Signaling....................15 | 5.4. Stability ..................................................... | |||
5.8. LSP Resource Utilization........................................15 | 5.5. Disruption Minimization ....................................... | |||
5.8.1. FA-LSP Release and Setup.......................................16 | 5.6. LSP Attribute Inheritance ..................................... | |||
5.8.2. Virtual TE-Links.............................................16 | 5.7. Computing Paths With and Without Nested Signaling ............. | |||
5.9. Verification of the LSPs........................................17 | 5.8. LSP Resource Utilization ...................................... | |||
6. Security Considerations...........................................18 | 5.8.1. FA-LSP Release and Setup .................................... | |||
7. IANA Considerations..............................................18 | 5.8.2. Virtual TE-Links ............................................ | |||
8. References......................................................18 | 5.9. Verification of the LSPs ...................................... | |||
8.1. Normative Reference.............................................18 | 6. Security Considerations ......................................... | |||
8.2. Informative References..........................................18 | 7. IANA Considerations ............................................ | |||
9. Authors' Addresses...............................................19 | 8. Acknowledgements ................................................ | |||
10. Contributors' Addresses..........................................20 | 9. References ...................................................... | |||
11. Intellectual Property Considerations...............................20 | 9.1. Normative Reference ........................................... | |||
12. Full Copyright Statement.........................................20 | 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 | ||||
1. Introduction | 1. Introduction | |||
Generalized MPLS (GMPLS) extends MPLS to handle multiple switching technologies: | Generalized MPLS (GMPLS) extends MPLS to handle multiple switching | |||
packet switching, layer-2 switching, TDM switching, wavelength switching, and | technologies: packet switching, layer-2 switching, TDM switching, | |||
fiber switching (see [RFC3945]). The Interface Switching Capability (ISC) | wavelength switching, and fiber switching (see [RFC3945]). The | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | Interface Switching Capability (ISC) concept is introduced for these | |||
switching technologies and is designated as follows: PSC (packet | ||||
switch capable), L2SC (Layer-2 switch capable), TDM (Time Division | ||||
Multiplex capable), LSC (lambda switch capable), and FSC (fiber | ||||
switch capable). | ||||
concept is introduced for these switching technologies and is designated as | The representation, in a GMPLS control plane, of a switching | |||
follows: PSC (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | technology domain is referred to as a region [RFC4206]. A switching | |||
Division Multiplex capable), LSC (lambda switch capable), and FSC (fiber switch | type describes the ability of a node to forward data of a particular | |||
capable). | data plane technology, and uniquely identifies a network region. A | |||
layer describes a data plane switching granularity level (e.g., VC4, | ||||
VC-12). A data plane layer is associated with a region in the control | ||||
plane (e.g., VC4 is associated with TDM, MPLS is associated with | ||||
PSC). However, more than one data plane layer can be associated with | ||||
the same region (e.g., both VC4 and VC12 are associated with TDM). | ||||
Thus, a control plane region, identified by its switching type value | ||||
(e.g., TDM), can be sub-divided into smaller granularity component | ||||
networks based on "data plane switching layers". The Interface | ||||
Switching Capability Descriptor (ISCD) [RFC4202], identifying the | ||||
interface switching capability (ISC), the encoding type, and the | ||||
switching bandwidth granularity, enables the characterization of the | ||||
associated layers. | ||||
The representation, in a GMPLS control plane, of a switching technology domain | In this document, we define a Multi Layer Network (MLN) to be a TE | |||
is referred to as a region [RFC4206]. A switching type describes the ability of | domain comprising multiple data plane switching layers either of the | |||
a node to forward data of a particular data plane technology, and uniquely | same ISC (e.g. TDM) or different ISC (e.g. TDM and PSC) and | |||
identifies a network region. A layer describes a data plane switching | controlled by a single GMPLS control plane instance. We further | |||
granularity level (e.g., VC4, VC-12). A data plane layer is associated with a | define a particular case of MLNs. A Multi Region Network (MRN) is | |||
region in the control plane (e.g., VC4 is associated with TDM, MPLS is | defined as a TE domain supporting at least two different switching | |||
associated with PSC). However, more than one data plane layer can be associated | technologies (e.g., PSC and TDM) hosted on the same devices (referred | |||
with the same region (e.g., both VC4 and VC12 are associated with TDM). Thus, a | to as multi-switching-type-capable LSRs, see below) and under the | |||
control plane region, identified by its switching type value (e.g., TDM), can be | control of a single GMPLS control plane instance. | |||
sub-divided into smaller granularity component networks based on "data plane | ||||
switching layers". The Interface Switching Capability Descriptor (ISCD) | ||||
[RFC4202], identifying the interface switching capability (ISC), the encoding | ||||
type, and the switching bandwidth granularity, enables the characterization of | ||||
the associated layers. | ||||
In this document, we define a Multi Layer Network (MLN) to be a TE domain | MLNs can be further categorized according to the distribution of the | |||
comprising multiple data plane switching layers either of the same ISC (e.g. | ISCs among the LSRs: | |||
TDM) or different ISC (e.g. TDM and PSC) and controlled by a single GMPLS | ||||
control plane instance. We further define a particular case of MLNs. A Multi | ||||
Region Network (MRN) is defined as a TE domain supporting at least two different | ||||
switching technologies (e.g. PSC + TDM) hosted on the same device (referred to | ||||
as multi-switching-type-capable LSRs, see below) and 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: | ||||
- Each LSR may support just one ISC. | - Each LSR may support just one ISC. | |||
Such LSRs are known as single-switching-type-capable LSRs. | Such LSRs are known as single-switching-type-capable LSRs. The MLN | |||
The MLN may comprise a set of single-switching-type-capable LSRs | may comprise a set of single-switching-type-capable LSRs some of | |||
that support different ISCs. | which support different ISCs. | |||
- Each LSR may support more than one ISC at the same time. | - Each LSR may support more than one ISC at the same time. | |||
Such LSRs are known as multi-switching-type-capable LSRs, and | Such LSRs are known as multi-switching-type-capable LSRs, and can | |||
can be further classified as either ‘‘simplex’’ or hybrid’’ nodes | be further classified as either "simplex" or "hybrid" nodes as | |||
as defined in Section 4.2. | defined in Section 4.2. | |||
- The MLN may be constructed from any combination of single-switching-type- | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
capable LSRs and multi-switching-type-capable LSRs. | ||||
Since GMPLS provides a comprehensive framework for the control of different | - The MLN may be constructed from any combination of single- | |||
switching capabilities, a single GMPLS instance controlling the MLN/MRN enables | switching-type-capable LSRs and multi-switching-type-capable LSRs. | |||
rapid service provisioning and efficient traffic engineering across all | ||||
switching capabilities. In such networks, TE Links are consolidated into a | ||||
single Traffic Engineering Database (TED). Since this TED contains the | ||||
information relative to all the different regions and layers existing in the | ||||
network, a path across multiple regions or layers can be computed using this TED. | ||||
Thus optimization of network resources can be achieved across the whole MLN/MRN. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | Since GMPLS provides a comprehensive framework for the control of | |||
different switching capabilities, a single GMPLS instance may be used | ||||
to control the MLN/MRN. This enables rapid service provisioning and | ||||
efficient traffic engineering across all switching capabilities. In | ||||
such networks, TE Links are consolidated into a single Traffic | ||||
Engineering Database (TED). Since this TED contains the information | ||||
relative to all the different regions and layers existing in the | ||||
network, a path across multiple regions or layers can be computed | ||||
using this TED. | ||||
Consider, for example, a MRN consisting of packet-switch capable routers and TDM | Thus optimization of network resources can be achieved across the | |||
cross-connects. Assume that a packet LSP is routed between source and | whole MLN/MRN. Consider, for example, a MRN consisting of packet- | |||
destination packet-switch capable routers, and that the LSP can be routed across | switch capable routers and TDM cross-connects. Assume that a packet | |||
the PSC-region (i.e., utilizing only resources of the packet region topology). | LSP is routed between source and destination packet-switch capable | |||
If the performance objective for the packet LSP is not satisfied, new TE links | routers, and that the LSP can be routed across the PSC-region (i.e., | |||
may be created between the packet-switch capable routers across the TDM-region | utilizing only resources of the packet region topology). If the | |||
(for example, VC-12 links) and the LSP can be routed over those TE links. | performance objective for the packet LSP is not satisfied, new TE | |||
Further, even if the LSP can be successfully established across the PSC-region, | links may be created between the packet-switch capable routers across | |||
TDM hierarchical LSPs across the TDM region between the packet-switch capable | the TDM-region (for example, VC-12 links) and the LSP can be routed | |||
routers may be established and used if doing so is necessary to meet the | over those TE links. | |||
operator's objectives for network resources availability (e.g., link bandwidth, | ||||
or adaptation ports between regions) across the regions. 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 | 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, or adaptation ports | ||||
between regions) across the regions. The same considerations hold | ||||
when VC4 LSPs are provisioned to provide extra flexibility for the | ||||
VC12 and/or VC11 layers in an MLN. | ||||
This document describes the requirements to support multi-region/multi-layer | 1.1. Scope | |||
networks. There is no intention to specify solution-specific and/or protocol | ||||
elements in this document. The applicability of existing GMPLS protocols and any | ||||
protocol extensions to the MRN/MLN is addressed in separate documents [MRN-EVAL]. | ||||
This document covers the elements of a single GMPLS control plane instance | This document describes the requirements to support multi-region/ | |||
controlling multiple layers within a given TE domain. A control plane instance | multi-layer networks. There is no intention to specify solution- | |||
can serve one, two or more layers. Other possible approaches such as having | specific and/or protocol elements in this document. The applicability | |||
multiple control plane instances serving disjoint sets of layers are outside the | of existing GMPLS protocols and any protocol extensions to the | |||
scope of this document. | MRN/MLN is addressed in separate documents [MRN-EVAL]. | |||
For such TE domain to interoperate with edge nodes/domains supporting interfaces | This document covers the elements of a single GMPLS control plane | |||
by other SDOs e.g. ITU-T and OIF, an interworking function may be needed. | instance controlling multiple layers within a given TE domain. A | |||
Location and specification of this function are outside the scope of this | control plane instance can serve one, two or more layers. Other | |||
document (because interworking aspects are strictly under the responsibility of | possible approaches such as having multiple control plane instances | |||
the interworking function.) | serving disjoint sets of layers are outside the scope of this | |||
document. It is most probable that such a MLN or MRN would be | ||||
operated by a single Service Provider, but this document does not | ||||
exclude the possibility of two layers (or regions) being under | ||||
different administrative control (for example, by different Service | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
This document assumes that the interconnection of adjacent MRN/MLN TE domains | Providers that share a single control plane instance) where the | |||
makes use of [RFC4726] when their edges also support inter-domain GMPLS RSVP-TE | administrative domains are prepared to share a limited amount of | |||
extensions. | information. | |||
2. Conventions Used in this Document | For such TE domain to interoperate with edge nodes/domains supporting | |||
non-GMPLS interfaces (such as those defined by other SDOs), an | ||||
interworking function may be needed. Location and specification of | ||||
this function are outside the scope of this document (because | ||||
interworking aspects are strictly under the responsibility of the | ||||
interworking function). | ||||
Although this is not a protocol specification, the key words "MUST", "MUST NOT", | This document assumes that the interconnection of adjacent MRN/MLN TE | |||
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | domains makes use of [RFC4726] when their edges also support inter- | |||
and "OPTIONAL" are used in this document to highlight requirements, and are to | domain GMPLS RSVP-TE extensions. | |||
be interpreted as described in RFC 2119 [RFC2119]. | ||||
2.1.List of acronyms | 2. Conventions Used in this Document | |||
MLN: Multi-Layer Network | Although this is not a protocol specification, the key words "MUST", | |||
MRN: Multi-Region Network | "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | "RECOMMENDED", "MAY", and "OPTIONAL" are used in this document to | |||
highlight requirements, and are to be interpreted as described in | ||||
RFC 2119 [RFC2119]. | ||||
2.1. List of Acronyms | ||||
FA: Forwarding Adjacency | ||||
FA-LSP: Forwarding Adjacency Label Switched Path | ||||
FSC: Fiber Switching Capable | ||||
ISC: Interface Switching Capability | ISC: Interface Switching Capability | |||
ISCD: Interface Switching Capability Descriptor | ISCD: Interface Switching Capability Descriptor | |||
PSC: Packet Switching Capable | ||||
L2SC: Layer-2 Switching Capable | L2SC: Layer-2 Switching Capable | |||
TDM: Time-Division Switch Capable | ||||
LSC: Lambda Switching Capable | LSC: Lambda Switching Capable | |||
FSC: Fiber Switching Capable | LSP: Label Switched Path | |||
LSR: Label Switching Router | ||||
MLN: Multi-Layer Network | ||||
MRN: Multi-Region Network | ||||
PSC: Packet Switching Capable | ||||
SRLG: Shared Risk Ling Group | SRLG: Shared Risk Ling Group | |||
VNT: Virtual Network Topology | TDM: Time-Division Switch Capable | |||
FA: Forwarding Adjacency | ||||
FA-LSP: Forwarding Adjacency Label Switched Path | ||||
TE: Traffic Engineering | TE: Traffic Engineering | |||
TED: Traffic Engineering Database | TED: Traffic Engineering Database | |||
LSP: Label Switched Path | VNT: Virtual Network Topology | |||
LSR: Label Switching Router | ||||
3. Positioning | 3. Positioning | |||
A multi-region network (MRN) is always a multi-layer network (MLN) since the | A multi-region network (MRN) is always a multi-layer network (MLN) | |||
network devices on region boundaries bring together different ISCs. A MLN, | since the network devices on region boundaries bring together | |||
however, is not necessarily a MRN since multiple layers could be fully contained | different ISCs. A MLN, however, is not necessarily a MRN since | |||
within a single region. For example, VC12, VC4, and VC4-4c are different layers | multiple layers could be fully contained within a single region. For | |||
of the TDM region. | example, VC12, VC4, and VC4-4c are different layers of the TDM | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
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 terminating | A data plane layer is a collection of network resources capable of | |||
and/or switching data traffic of a particular format [RFC4397]. These resources | terminating and/or switching data traffic of a particular format | |||
can be used for establishing LSPs for traffic delivery. For example, VC-11 and | [RFC4397]. These resources can be used for establishing LSPs for | |||
VC4-64c represent two different layers. | traffic delivery. For example, VC-11 and VC4-64c represent two | |||
different layers. | ||||
From the control plane viewpoint, an LSP region is defined as a set of one or | From the control plane viewpoint, an LSP region is defined as a set | |||
more data plane layers that share the same type of switching technology, that is, | of one or more data plane layers that share the same type of | |||
the same switching type. For example, VC-11, VC-4, and VC-4-7v layers are part | switching technology, that is, the same switching type. For example, | |||
of the same TDM region. The regions that are currently defined are: PSC, L2SC, | VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. The | |||
TDM, LSC, and FSC. Hence, an LSP region is a technology domain (identified by | regions that are currently defined are: PSC, L2SC, TDM, LSC, and FSC. | |||
the ISC type) for which data plane resources (i.e., data links) are represented | Hence, an LSP region is a technology domain (identified by the ISC | |||
into the control plane as an aggregate of TE information associated with a set | type) for which data plane resources (i.e., data links) are | |||
of links (i.e., TE links). For example VC-11 and VC4-64c capable TE links are | represented into the control plane as an aggregate of TE information | |||
part of the same TDM region. Multiple layers can thus exist in a single region | associated with a set of links (i.e., TE links). For example VC-11 | |||
network. | and VC4-64c capable TE links are part of the same TDM region. | |||
Multiple layers can thus exist in a single region network. | ||||
Note also that the region may produce a distinction within the control plane. | Note also that the region may produce a distinction within the | |||
Layers of the same region share the same switching technology and, therefore, | control plane. Layers of the same region share the same switching | |||
use the same set of technology-specific signaling objects and technology- | technology and, therefore, use the same set of technology-specific | |||
specific value setting of TE link attributes within the control plane, but | signaling objects and technology-specific value setting of TE link | |||
layers from different regions may use different technology-specific objects and | attributes within the control plane, but layers from different | |||
TE attribute values. This means that it may not be possible to simply forward | regions may use different technology-specific objects and TE | |||
the signaling message between LSR hosting different switching technologies | attribute values. This means that it may not be possible to simply | |||
because change in some of the signaling objects (for example, the traffic | forward the signaling message between LSR hosting different switching | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | technologies because change in some of the signaling objects (for | |||
example, the traffic parameters) when crossing a region boundary even | ||||
if a single control plane instance is used to manage the whole MRN. | ||||
We may solve this issue by using triggered signaling (see Section | ||||
4.3.1). | ||||
parameters) when crossing a region boundary even if a single control plane | 3.2. Service Layer Networks | |||
instance is used to manage the whole MRN. We may solve the issue by using | ||||
triggered signaling (See 4.3.1). | ||||
3.2. Service layer networks | A service provider's network may be divided into different service | |||
layers. The customer's network is considered from the provider's | ||||
perspective as the highest service layer. It interfaces to the | ||||
highest service layer of the service provider's network. Connectivity | ||||
across the highest service layer of the service provider's network | ||||
may be provided with support from successively lower service layers. | ||||
Service layers are realized via a hierarchy of network layers located | ||||
generally in several regions and commonly arranged according to the | ||||
switching capabilities of network devices. | ||||
A service provider's network may be divided into different service layers. The | For instance some customers purchase Layer 1 (i.e., transport) | |||
customer's network is considered from the provider's perspective as the highest | services from the service provider, some Layer 2 (e.g., ATM), while | |||
service layer. It interfaces to the highest service layer of the service | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
provider's network. Connectivity across the highest service layer of the service | ||||
provider's network may be provided with support from successively lower service | ||||
layers. Service layers are realized via a hierarchy of network layers located | ||||
generally in several regions and commonly arranged according to the switching | ||||
capabilities of network devices. | ||||
For instance some customers purchase Layer 1 (i.e., transport) services from the | others purchase Layer 3 (IP/MPLS) services. The service provider | |||
service provider, some Layer 2 (e.g., ATM), while others purchase Layer 3 | realizes the services by a stack of network layers located within one | |||
(IP/MPLS) services. The service provider realizes the services by a stack of | or more network regions. The network layers are commonly arranged | |||
network layers located within one or more network regions. The network layers | according to the switching capabilities of the devices in the | |||
are commonly 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 the GMPLS-based | GMPLS-based multi-region/multi-layer network. For example, a Layer 1 | |||
multi-region/multi-layer network. For example, a Layer 1 service (realized via | service (realized via the network layers of TDM, and/or LSC, and/or | |||
the network layers of TDM, and/or LSC, and/or FSC regions) may support a Layer 2 | FSC regions) may support a Layer 2 network (realized via ATM VP/VC) | |||
network (realized via ATM VP/VC) which may itself support a Layer 3 network | which may itself support a Layer 3 network (IP/MPLS region). The | |||
(IP/MPLS region). The supported data plane relationship is a data plane client- | supported data plane relationship is a data plane client-server | |||
server relationship where the lower layer provides a service for the higher | relationship where the lower layer provides a service for the higher | |||
layer using the data links realized in the lower layer. | layer using the data links realized in the lower layer. | |||
Services provided by a GMPLS-based multi-region/multi-layer network are referred | Services provided by a GMPLS-based multi-region/multi-layer network | |||
to as "Multi-region/Multi-layer network services". For example, legacy IP and | are referred to as "Multi-region/Multi-layer network services". For | |||
IP/MPLS networks can be supported on top of multi-region/multi-layer networks. | example, legacy IP and IP/MPLS networks can be supported on top of | |||
It has to be emphasized that delivery of such diverse services is a strong | multi-region/multi-layer networks. It has to be emphasized that | |||
motivator for the deployment of multi-region/multi-layer networks. | delivery of such diverse services is a strong motivator for the | |||
deployment of multi-region/multi-layer networks. | ||||
A customer network may be provided on top of a server GMPLS-based MRN/MLN which | A customer network may be provided on top of a server GMPLS-based | |||
is operated by a service provider. For example, a pure IP and/or an IP/MPLS | MRN/MLN which is operated by a service provider. For example, a pure | |||
network can be provided on top of GMPLS-based packet over optical networks | IP and/or an IP/MPLS network can be provided on top of GMPLS-based | |||
[MPLS-GMPLS]. The relationship between the networks is a client/server | packet over optical networks [MPLS-GMPLS]. The relationship between | |||
relationship and, such services are referred to as "MRN/MLN services". In this | the networks is a client/server relationship and, such services are | |||
case, the customer network may form part of the MRN/MLN, or may be partially | referred to as "MRN/MLN services". In this case, the customer network | |||
separated, for example to maintain separate routing information but retain | may form part of the MRN/MLN, or may be partially separated, for | |||
common signaling. | example to maintain separate routing information but 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 within a network | Vertical interaction is defined as the collaborative mechanisms | |||
element that is capable of supporting more than one layer or region and of | within a network element that is capable of supporting more than one | |||
realizing the client/server relationships between the layers or regions. | layer or region and of realizing the client/server relationships | |||
Protocol exchanges between two network controllers managing different regions or | between the layers or regions. Protocol exchanges between two network | |||
layers are also a vertical interaction. Integration of these interactions as | controllers managing different regions or layers are also a vertical | |||
part of the control plane is referred to as vertical integration. Thus, this | interaction. Integration of these interactions as part of the control | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | plane is referred to as vertical integration. Thus, this refers to | |||
the collaborative mechanisms within a single control plane instance | ||||
driving multiple network layers part of the same region or not. Such | ||||
a concept is useful in order to construct a framework that | ||||
facilitates efficient network resource usage and rapid service | ||||
provisioning in carrier networks that are based on multiple layers, | ||||
switching technologies, or ISCs. | ||||
refers to the collaborative mechanisms within a single control plane instance | Horizontal interaction is defined as the protocol exchange between | |||
driving multiple network layers part of the same region or not. Such a concept | network controllers that manage transport nodes within a given layer | |||
is useful in order to construct a framework that facilitates efficient network | or region. For instance, the control plane interaction between two | |||
resource usage and rapid service provisioning in carrier networks that are based | TDM network elements switching at OC-48 is an example of horizontal | |||
on multiple layers, switching technologies, or ISCs. | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
Horizontal interaction is defined as the protocol exchange between network | interaction. GMPLS protocol operations handle horizontal interactions | |||
controllers that manage transport nodes within a given layer or region. For | within the same routing area. The case where the interaction takes | |||
instance, the control plane interaction between two TDM network elements | place across a domain boundary, such as between two routing areas | |||
switching at OC-48 is an example of horizontal interaction. GMPLS protocol | within the same network layer, is evaluated as part of the inter- | |||
operations handle horizontal interactions within the same routing area. The case | domain work [RFC4726], and is referred to as horizontal integration. | |||
where the interaction takes place across a domain boundary, such as between two | Thus, horizontal integration refers to the collaborative mechanisms | |||
routing areas within the same network layer, is evaluated as part of the inter- | between network partitions and/or administrative divisions such as | |||
domain work [RFC4726], and is referred to as horizontal integration. Thus, | routing areas or autonomous systems. | |||
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 domains match | This distinction needs further clarification when administrative | |||
layer/region boundaries. Horizontal interaction is extended to cover such cases. | domains match layer/region boundaries. Horizontal interaction is | |||
For example, the collaborative mechanisms in place between two lambda switching | extended to cover such cases. For example, the collaborative | |||
capable areas relate to horizontal integration. On the other hand, the | mechanisms in place between two lambda switching capable areas relate | |||
collaborative mechanisms in place between a packet switching capable (e.g. | to horizontal integration. On the other hand, the collaborative | |||
IP/MPLS) domain over a different time division switching capable (eg VC4 SDH) | mechanisms in place between a packet switching capable (e.g., | |||
domain is part of the horizontal integration while it can be seen as a first | IP/MPLS) domain and a separate time division switching capable | |||
step towards vertical integration. | (e.g., VC4 SDH) domain over which it operates are part of the | |||
horizontal integration while it can also be seen as a first step | ||||
towards vertical integration. | ||||
3.4.Motivation | 3.4.Motivation | |||
The applicability of GMPLS to multiple switching technologies provides the | The applicability of GMPLS to multiple switching technologies | |||
unified control management approach for both LSP provisioning and recovery. | provides a unified control and management approach for both LSP | |||
Indeed, one of the main motivations for unifying the capabilities and operations | provisioning and recovery. Indeed, one of the main motivations for | |||
GMPLS control plane is the desire to support multi LSP-region [RFC4206] routing | unifying the capabilities and operations of the GMPLS control plane | |||
and Traffic Engineering (TE) capability. For instance, this enables effective | is the desire to support multi-LSP-region [RFC4206] routing and | |||
network resource utilization of both the Packet/Layer2 LSP regions and the Time | Traffic Engineering (TE) capabilities. For instance, this enables | |||
Division Multiplexing (TDM) or Lambda LSP regions in high capacity networks. | effective network resource utilization of both the Packet/Layer2 LSP | |||
regions and the Time Division Multiplexing (TDM) or Lambda LSP | ||||
regions in high capacity networks. | ||||
The rationales for GMPLS controlled multi-layer/multi-region networks | ||||
are summarized below: | ||||
- The maintenance of multiple instances of the control plane on | ||||
devices hosting more than one switching capability not only | ||||
increases the complexity of their interactions but also increases | ||||
the total amount of processing individual instances would handle. | ||||
The rationales for GMPLS controlled multi-layer/multi-region networks context | ||||
are summarized here below: | ||||
- The maintenance of multiple instances of the control plane on devices hosting | ||||
more than one switching capability not only increases the complexity of their | ||||
interactions but also increases 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 multiple | |||
identification for the same object (a link for instance or more generally any | identifiers for the same object (a link, for instance, or more | |||
network resource), on the other hand such aggregation does not impact the | generally, any network resource). On the other hand such | |||
separation between the control and the data plane. | aggregation does not impact the separation between the control | |||
- By maintaining a single routing protocol instance and a single TE database | plane and the data plane. | |||
per LSR, a unified control plane model prevents from maintaining a dedicated | ||||
routing topology per layer and therefore does not mandate a full mesh of | ||||
routing adjacencies as it is the case with overlaid control planes. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | - By maintaining a single routing protocol instance and a single TE | |||
database per LSR, a unified control plane model removes the | ||||
requirement to maintain a dedicated routing topology per layer and | ||||
therefore does not mandate a full mesh of routing adjacencies as is | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
the case with overlaid control planes. | ||||
- The collaboration between technology layers where the control | ||||
channel is associated with the data channel (e.g. packet/framed | ||||
data planes) and technology layers where the control channel is not | ||||
directly associated with the data channel (SONET/SDH, G.709, etc.) | ||||
is facilitated by the capability within GMPLS to associate in-band | ||||
control plane signaling to the IP terminating interfaces of the | ||||
control plane. | ||||
- The collaboration between associated control planes (packet/framed data | ||||
planes) and non-associated control planes (SONET/SDH, G.709, etc.) is | ||||
facilitated due to the capability of hooking the associated in-band signaling | ||||
to the IP terminating interfaces 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 such | |||
environment is facilitated (less control to management interactions) and more | a MRN/MLN is made more simple (fewer control to management | |||
scalable (through the use of aggregated information). | interactions) and more scalable (through the use of aggregated | |||
- Multi-region/multi-layer traffic engineering is facilitated as TE-links from | information). | |||
distinct regions/layers are stored within the same TE Database. | ||||
- Multi-region/multi-layer traffic engineering is facilitated as | ||||
TE-links from distinct regions/layers are stored within the same 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 of either | A network comprising transport nodes with multiple data plane layers | |||
the same ISC or different ISCs, controlled by a single GMPLS control plane | of either the same ISC or different ISCs, controlled by a single | |||
instance, is called a Multi-Layer Network (MLN). A sub-set of MLNs consists of | GMPLS control plane instance, is called a Multi-Layer Network (MLN). | |||
networks supporting LSPs of different switching technologies (ISCs). A network | A sub-set of MLNs consists of networks supporting LSPs of different | |||
supporting more than one switching technology is called a Multi-Region Network | switching technologies (ISCs). A network supporting more than one | |||
(MRN). | 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 support | The Interface Switching Capability (ISC) is introduced in GMPLS to | |||
various kinds of switching technology in a unified way [RFC4202]. An ISC is | support various kinds of switching technology in a unified way | |||
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) describes | A switching type (also referred to as the switching capability type) | |||
the ability of a node to forward data of a particular data plane technology, and | describes the ability of a node to forward data of a particular data | |||
uniquely identifies a network region. The following ISC types (and, hence, | plane technology, and uniquely identifies a network region. The | |||
regions) are defined: PSC, L2SC, TDM, LSC, and FSC. Each end of a data link | following ISC types (and, hence, regions) are defined: PSC, L2SC, | |||
(more precisely, each interface connecting a data link to a node) in a GMPLS | TDM, LSC, and FSC. Each end of a data link (more precisely, each | |||
network is associated with an ISC. | interface connecting a data link to a node) in a GMPLS network is | |||
associated with an ISC. | ||||
The ISC value is advertised as a part of the Interface Switching Capability | The ISC value is advertised as a part of the Interface Switching | |||
Descriptor (ISCD) attribute (sub-TLV) of a TE link end associated with a | Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end | |||
particular link interface [RFC4202]. Apart from the ISC, the ISCD contains | associated with a particular link interface [RFC4202]. Apart from the | |||
information including the encoding type, the bandwidth granularity, and the | ISC, the ISCD contains information including the encoding type, the | |||
unreserved bandwidth on each of eight priorities at which LSPs can be | bandwidth granularity, and the unreserved bandwidth on each of eight | |||
established. The ISCD does not "identify" network layers, it uniquely | priorities at which LSPs can be established. The ISCD does not | |||
characterizes information associated to one or more network layers. | "identify" network layers, it uniquely characterizes information | |||
associated to one or more network layers. | ||||
TE link end advertisements may contain multiple ISCDs. This can be interpreted | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
as advertising a multi-layer (or multi-switching-capable) TE link end. That is, | ||||
the TE link end (and therefore the TE link) is present in multiple layers. | ||||
4.2. Multiple Interface Switching Capabilities | TE link end advertisements may contain multiple ISCDs. This can be | |||
interpreted as advertising a multi-layer (or multi-switching-capable) | ||||
TE link end. That is, the TE link end (and therefore the TE link) is | ||||
present in multiple layers. | ||||
In an MLN, network elements may be single-switching-type-capable or multi- | 4.2. Multiple Interface Switching Capabilities | |||
switching-type-capable nodes. Single-switching-type-capable 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). This case is described in [RFC4202]. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | In an MLN, network elements may be single-switching-type-capable or | |||
multi-switching-type-capable nodes. Single-switching-type-capable | ||||
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). | ||||
This case is described in [RFC4202]. | ||||
Multi-switching-type-capable LSRs are classified as "simplex" or "hybrid" nodes. | Multi-switching-type-capable LSRs are classified as "simplex" or | |||
Simplex and hybrid nodes are categorized according to the way they advertise | "hybrid" nodes. Simplex and hybrid nodes are categorized according to | |||
these multiple ISCs: | the way they advertise these multiple ISCs: | |||
- A simplex node can terminate data links with different switching capabilities | - A simplex node can terminate data links with different switching | |||
where each data link is connected to the node by a separate link interface. | capabilities where each data link is connected to the node by a | |||
So, it advertises several TE Links each with a single ISC value carried in | separate link interface. So, it advertises several TE Links each | |||
its ISCD sub-TLV. For example, an LSR with PSC and TDM links each of which is | with a single ISC value carried in its ISCD sub-TLV. For example, | |||
connected to the LSR via a separate interface. | an LSR with PSC and TDM links each of which is connected to the LSR | |||
via a separate interface. | ||||
- A hybrid node can terminate data links with different switching capabilities | - A hybrid node can terminate data links with different switching | |||
where the data links are connected to the node by the same interface. So, it | capabilities where the data links are connected to the node by the | |||
advertises a single TE Link containing more than one ISCD each with a | same interface. So, it advertises a single TE Link containing more | |||
different ISC value. For example, a node may terminate PSC and TDM data links | than one ISCD each with a different ISC value. For example, a node | |||
and interconnect those external data links via internal links. The external | may terminate PSC and TDM data links and interconnect those | |||
interfaces connected to the node have both PSC and TDM capabilities. | external data links via internal links. The external interfaces | |||
connected to the node have both PSC and TDM capabilities. | ||||
Additionally, TE link advertisements issued by a simplex or a hybrid node may | Additionally, TE link advertisements issued by a simplex or a hybrid | |||
need to provide information about the node's internal adaptation capabilities | node may need to provide information about the node's internal | |||
between the switching technologies supported. That is, the node's capability to | adaptation capabilities between the switching technologies supported. | |||
perform layer border node functions. | That is, the node's capability to perform layer border node | |||
functions. This information allows path computation to select an end- | ||||
to-end multi-layer or multi-region path that includes links of | ||||
different switching capabilities that are joined by LSRs that can | ||||
adapt the signal between the links. | ||||
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes | 4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes | |||
This type of network contains at least one hybrid node, zero or more simplex | This type of network contains at least one hybrid node, zero or more | |||
nodes, and a set of single-switching-type-capable nodes. | simplex nodes, and a set of single-switching-type-capable nodes. | |||
Figure 1 shows an example hybrid node. The hybrid node has two switching | Figure 1 shows an example hybrid node. The hybrid node has two | |||
elements (matrices), which support, for instance, TDM and PSC switching | switching elements (matrices), which support, for instance, TDM and | |||
respectively. The node terminates a PSC and a TDM link (Link1 and Link2 | PSC switching respectively. The node terminates a PSC and a TDM link | |||
respectively). It also has an internal link connecting the two switching | (Link1 and Link2 respectively). It also has an internal link | |||
elements. | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
The two switching elements are internally interconnected in such a way that it | connecting the two switching elements. | |||
is possible to terminate some of the resources of, say, Link2 and provide | ||||
adaptation for PSC traffic received/sent over the PSC interface (#b). This | The two switching elements are internally interconnected in such a | |||
situation is modeled in GMPLS by connecting the local end of Link2 to the TDM | way that it is possible to terminate some of the resources of, say, | |||
switching element via an additional interface realizing the | Link2 and provide adaptation for PSC traffic received/sent over the | |||
termination/adaptation function. There are two possible ways to set up PSC LSPs | PSC interface (#b). This situation is modeled in GMPLS by connecting | |||
through the hybrid node. Available resource advertisement (i.e., Unreserved and | the local end of Link2 to the TDM switching element via an additional | |||
Min/Max LSP Bandwidth) should cover both of these methods. | interface realizing the termination/adaptation function. There are | |||
two possible ways to set up PSC LSPs through the hybrid node. | ||||
Available resource advertisement (i.e., Unreserved and Min/Max LSP | ||||
Bandwidth) should cover both of these methods. | ||||
Network element | Network element | |||
............................. | ............................. | |||
: -------- : | : -------- : | |||
: | PSC | : | : | PSC | : | |||
Link1 -------------<->--|#a | : | Link1 -------------<->--|#a | : | |||
: | | : | ||||
: +--<->---|#b | : | : +--<->---|#b | : | |||
: | -------- : | : | -------- : | |||
TDM : | ---------- : | : | ---------- : | |||
+PSC : +--<->--|#c TDM | : | TDM : +--<->--|#c TDM | : | |||
+PSC : | | : | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
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 consolidated | In GMPLS-based multi-region/multi-layer networks, TE Links may be | |||
into a single Traffic Engineering Database (TED) for use by the single control | consolidated into a single Traffic Engineering Database (TED) for use | |||
plane instance. Since this TED contains the information relative to all the | by the single control plane instance. Since this TED contains the | |||
layers of all regions in the network, a path across multiple layers (possibly | information relative to all the layers of all regions in the network, | |||
crossing multiple regions) can be computed using the information in this TED. | a path across multiple layers (possibly crossing multiple regions) | |||
Thus, optimization of network resources across the multiple layers of the same | can be computed using the information in this TED. Thus, optimization | |||
region and across multiple regions can be achieved. | of network resources across the multiple layers of the same region | |||
and across multiple regions can be achieved. | ||||
These concepts allow for the operation of one network layer over the topology | These concepts allow for the operation of one network layer over the | |||
(that is, TE links) provided by other network layers (for example, the use of a | topology (that is, TE links) provided by other network layers (for | |||
lower layer LSC LSP carrying PSC LSPs). In turn, a greater degree of control and | example, the use of a lower layer LSC LSP carrying PSC LSPs). In | |||
inter-working can be achieved, including (but not limited too): | 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-switching- | Note that in a multi-layer/multi-region network that includes multi- | |||
type-capable nodes, an explicit route used to establish an end-to-end LSP can | switching-type-capable nodes, an explicit route used to establish an | |||
specify nodes that belong to different layers or regions. In this case, a | end-to-end LSP can specify nodes that belong to different layers or | |||
mechanism to control the dynamic creation of FA LSPs may be required (see | regions. In this case, a mechanism to control the dynamic creation of | |||
Sections 4.3.2 and 4.3.3). | 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 dynamically | There is a full spectrum of options to control how FA-LSPs are | |||
established. The process can be subject to the control of a policy, which may be | dynamically established. The process can be subject to the control of | |||
set by a management component, and which may require that the management plane | a policy, which may be set by a management component, and which may | |||
is consulted at the time that the FA LSP is established. Alternatively, the FA | require that the management plane is consulted at the time that the | |||
LSP can be established at the request of the control plane without any | FA-LSP is established. Alternatively, the FA-LSP can be established | |||
management control. | 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 may be | When an LSP crosses the boundary from an upper to a lower layer, it | |||
nested into a lower layer FA LSP that crosses the lower layer. From a signaling | may be nested into a lower layer FA-LSP that crosses the lower layer. | |||
perspective, there are two alternatives to establish the lower layer FA LSP: | From a signaling perspective, there are two alternatives to establish | |||
static (pre-provisioned) and dynamic (triggered). A pre-provisioned FA-LSP may | the lower layer FA-LSP: static (pre-provisioned) and dynamic | |||
be initiated either by the operator or automatically using features like TE | (triggered). A pre-provisioned FA-LSP may be initiated either by the | |||
auto-mesh [AUTO-MESH]. If such a lower layer LSP does not already exist, the LSP | operator or automatically using features like TE auto-mesh | |||
may be established dynamically. Such a mechanism is referred to as "triggered | [RFC4972]. If such a lower layer LSP does not already exist, the LSP | |||
signaling". | may be established dynamically. Such a mechanism is referred to as | |||
"triggered signaling". | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
4.3.2. FA-LSPs | 4.3.2. FA-LSPs | |||
Once an LSP is created across a layer from one layer border node to another, it | Once an LSP is created across a layer from one layer border node to | |||
can be used as a data link in an upper layer. | another, it can be used as a data link in an upper layer. | |||
Furthermore, it can be advertised as a TE-link, allowing other nodes to consider | Furthermore, it can be advertised as a TE-link, allowing other nodes | |||
the LSP as a TE link for their path computation [RFC4206]. An LSP created either | to consider the LSP as a TE link for their path computation | |||
statically or dynamically by one instance of the control plane and advertised as | [RFC4206]. An LSP created either statically or dynamically by one | |||
a TE link into the same instance of the control plane is called a Forwarding | instance of the control plane and advertised as a TE link into the | |||
Adjacency LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE link | same instance of the control plane is called a Forwarding Adjacency | |||
is called a Forwarding Adjacency (FA). An FA has the special characteristic of | LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE link | |||
not requiring a routing adjacency (peering) between its end points yet still | is called a Forwarding Adjacency (FA). An FA has the special | |||
guaranteeing control plane connectivity between the FA-LSP end points based on a | characteristic of not requiring a routing adjacency (peering) between | |||
signaling adjacency. An FA is a useful and powerful tool for improving the | its end points yet still guaranteeing control plane connectivity | |||
scalability of GMPLS Traffic Engineering (TE) capable networks since multiple | between the FA-LSP end points based on a signaling adjacency. An FA | |||
higher layer LSPs may be nested (aggregated) over a single FA-LSP. | is a useful and powerful tool for improving the scalability of GMPLS | |||
Traffic Engineering (TE) capable networks 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) LSP | The aggregation of LSPs enables the creation of a vertical (nested) | |||
Hierarchy. A set of FA-LSPs across or within a lower layer can be used during | LSP Hierarchy. A set of FA-LSPs across or within a lower layer can be | |||
path selection by a higher layer LSP. Likewise, the higher layer LSPs may be | used during path selection by a higher layer LSP. Likewise, the | |||
carried over dynamic data links realized via LSPs (just as they are carried over | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
any "regular" static data links). This process requires the nesting of LSPs | ||||
through a hierarchical process [RFC4206]. The TED contains a set of LSP | ||||
advertisements from different layers that are identified by the ISCD contained | ||||
within the TE link advertisement associated with the LSP [RFC4202]. | ||||
If a lower layer LSP is not advertised as an FA, it can still be used to carry | higher layer LSPs may be carried over dynamic data links realized via | |||
higher layer LSPs across the lower layer. For example, if the LSP is set up | LSPs (just as they are carried over any "regular" static data links). | |||
using triggered signaling, it will be used to carry the higher layer LSP that | This process requires the nesting of LSPs through a hierarchical | |||
caused the trigger. Further, the lower layer remains available for use by other | process [RFC4206]. The TED contains a set of LSP advertisements from | |||
higher layer LSPs arriving at the boundary. | different layers that are identified by the ISCD contained within the | |||
TE link advertisement associated with the LSP [RFC4202]. | ||||
Under some circumstances it may be useful to control the advertisement of LSPs | If a lower layer LSP is not advertised as an FA, it can still be used | |||
as FAs during the signaling establishment of the LSPs [DYN-HIER]. | to carry higher layer LSPs across the lower layer. For example, if | |||
the LSP is set up using triggered signaling, it will be used to carry | ||||
the higher layer LSP that caused the trigger. Further, the lower | ||||
layer remains available for use by other higher layer LSPs arriving | ||||
at the boundary. | ||||
Under some circumstances it may be useful to control the | ||||
advertisement of LSPs as FAs during the signaling establishment of | ||||
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 efficient path | A set of one or more of lower-layer LSPs provides information for | |||
handling in upper-layer(s) of the MLN, or, in other words, provides a virtual | efficient path handling in upper-layer(s) of the MLN, or, in other | |||
network topology (VNT) to the upper-layers. For instance, a set of LSPs, each of | words, provides a virtual network topology (VNT) to the upper-layers. | |||
which is supported by an LSC LSP, provides a virtual network topology to the | For instance, a set of LSPs, each of which is supported by an LSC | |||
layers of a PSC region, assuming that the PSC region is connected to the LSC | LSP, provides a virtual network topology to the layers of a PSC | |||
region. Note that a single lower-layer LSP is a special case of the VNT. The | region, assuming that the PSC region is connected to the LSC region. | |||
virtual network topology is configured by setting up or tearing down the lower | Note that a single lower-layer LSP is a special case of the VNT. The | |||
layer LSPs. By using GMPLS signaling and routing protocols, the virtual network | virtual network topology is configured by setting up or tearing down | |||
topology can be adapted to traffic demands. | the lower layer LSPs. By using GMPLS signaling and 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 diversely-routed | A lower-layer LSP appears as a TE-link in the VNT. Whether the | |||
lower-layer LSPs are used or not, the routes of lower-layer LSPs are hidden from | diversely-routed lower-layer LSPs are used or not, the routes of | |||
the upper layer in the VNT. Thus, the VNT simplifies the upper-layer routing and | lower-layer LSPs are hidden from the upper layer in the VNT. Thus, | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | the VNT simplifies the upper-layer routing and traffic engineering | |||
decisions by hiding the routes taken by the lower-layer LSPs. | ||||
However, hiding the routes of the lower-layer LSPs may lose important | ||||
information that is needed to make the higher-layer LSPs reliable. | ||||
For instance, the routing and traffic engineering in the IP/MPLS | ||||
layer does not usually consider how the IP/MPLS TE links are formed | ||||
from optical paths that are routed in the fiber layer. Two optical | ||||
paths may share the same fiber link in the lower-layer and therefore | ||||
they may both fail if the fiber link is cut. Thus the shared risk | ||||
properties of the TE links in the VNT must be made available to the | ||||
higher layer during path computation. Further, the topology of the | ||||
VNT should be designed so that any single fiber cut does not bisect | ||||
the VNT. These issues are addressed later in this document. | ||||
traffic engineering decisions by hiding the routes taken by the lower-layer LSPs. | Reconfiguration of the virtual network topology may be triggered by | |||
However hiding the routes of the lower-layer LSPs may lose important information | traffic demand changes, topology configuration changes, signaling | |||
that is needed to make the higher-layer LSPs reliable. For instance, the routing | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
and traffic engineering in the IP/MPLS layer does not usually consider how the | ||||
IP/MPLS TE links are formed from optical paths that are routed in the fiber | ||||
layer. Two optical paths may share the same fiber link in the lower-layer and | ||||
therefore they may both fail if the fiber link is cut. Thus the shared risk | ||||
properties of the TE links in the VNT must be made available to the higher layer | ||||
during path computation. Further, the topology of the VNT should be designed so | ||||
that any single fiber cut does not bisect the VNT. These issues are addressed | ||||
later in this document. | ||||
Reconfiguration of the virtual network topology may be triggered by traffic | requests from the upper layer, and network failures. For instance, by | |||
demand changes, topology configuration changes, signaling requests from the | reconfiguring the virtual network topology according to the traffic | |||
upper layer, and network failures. For instance, by reconfiguring the virtual | demand between source and destination node pairs, network performance | |||
network topology according to the traffic demand between source and destination | factors, such as maximum link utilization and residual capacity of | |||
node pairs, network performance factors, such as maximum link utilization and | the network, can be optimized. Reconfiguration is performed by | |||
residual capacity of the network, can be optimized. Reconfiguration is performed | computing the new VNT from the traffic demand matrix and optionally | |||
by computing the new VNT from the traffic demand matrix and optionally from the | from the current VNT. Exact details are outside the scope of this | |||
current VNT. Exact details are outside the scope of this document. However, this | document. However, this method may be tailored according to the | |||
method may be tailored according to the service provider's policy regarding | service provider's policy regarding network performance and quality | |||
network performance and quality of service (delay, loss/disruption, utilization, | of service (delay, loss/disruption, utilization, residual capacity, | |||
residual capacity, reliability). | reliability). | |||
5.Requirements | 5.Requirements | |||
5.1.Handling Single-Switching and Multi-Switching-Type-Capable Nodes | 5.1.Handling Single-Switching and Multi-Switching-Type-Capable Nodes | |||
The MRN/MLN can consist of single-switching-type-capable and multi-switching- | The MRN/MLN can consist of single-switching-type-capable and multi- | |||
type-capable nodes. The path computation mechanism in the MLN SHOULD be able to | switching-type-capable nodes. The path computation mechanism in the | |||
compute paths consisting of any combination of such nodes. | MLN SHOULD be able to compute paths consisting of any combination of | |||
such nodes. | ||||
Both single-switching-type-capable and multi-switching-type-capable (simplex or | Both single-switching-type-capable and multi-switching-type-capable | |||
hybrid) nodes could play the role of layer boundary. MRN/MLN Path computation | (simplex or hybrid) nodes could play the role of layer boundary. | |||
SHOULD handle TE topologies built of any combination of nodes | MRN/MLN Path computation SHOULD handle TE topologies built of any | |||
combination of nodes. | ||||
5.2. Advertisement of the Available Adaptation Resource | 5.2. Advertisement of the Available Adaptation Resource | |||
A hybrid node SHOULD maintain resources on its internal links (the links | A hybrid node SHOULD maintain resources on its internal links (the | |||
required for vertical (layer) integration) and SHOULD advertise the resource | links required for vertical (layer) integration) and SHOULD advertise | |||
information for those links. Likewise, path computation elements SHOULD be | the resource information for those links. Likewise, path computation | |||
prepared to use the availability of termination/adaptation resources as a | elements SHOULD be prepared to use the availability of termination/ | |||
constraint in MRN/MLN path computations to reduce the higher layer LSP setup | adaptation resources as a constraint in MRN/MLN path computations to | |||
blocking probability caused by the lack of necessary termination/ adaptation | reduce the higher layer LSP setup blocking probability caused by the | |||
resources in the lower layer(s). | lack of necessary termination/adaptation resources in the lower | |||
layer(s). | ||||
The advertisement of the adaptation capability to terminate LSPs of lower-region | The advertisement of the adaptation capability to terminate LSPs of | |||
and forward traffic in the upper-region is REQUIRED, as it provides critical | lower-region and forward traffic in the upper-region is REQUIRED, as | |||
information when performing multi-region path computation. | it provides critical information when performing multi-region path | |||
computation. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | The mechanism SHOULD cover the case where the upper-layer links which | |||
are directly connected to upper-layer switching element and the ones | ||||
which are connected through internal links between upper-layer | ||||
element and lower-layer element coexist (see Section 4.2.1). | ||||
The mechanism SHOULD cover the case where the upper-layer links which are | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
directly connected to upper-layer switching element and 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 a unified traffic engineering and routing model. | The MRN/MLN relies on unified routing and traffic engineering | |||
- Unified routing model: by maintaining a single routing protocol instance and | models. | |||
a single TE database per LSR, a unified control plane model prevents from | ||||
maintaining a dedicated routing topology per layer and therefore does not | ||||
mandate a full mesh of routing adjacencies per layer. | ||||
- Unified TE model: the TED in each LSR is populated with TE-links from all | ||||
layers of all regions (TE links interfaces on multiple-switching capability | ||||
LSR can be advertised with multiple ISCD). This may lead to a large amount of | ||||
information that has to be flooded and stored within the network. | ||||
Furthermore, path computation times, which may be of great importance during | - Unified routing model: By maintaining a single routing protocol | |||
restoration, will depend on the size of the TED. | instance and a single TE database per LSR, a unified control plane | |||
model removes the requirement to maintain a dedicated routing | ||||
topology per layer, and therefore does not mandate a full mesh of | ||||
routing adjacencies per layer. | ||||
- Unified TE model: The TED in each LSR is populated with TE-links | ||||
from all layers of all regions (TE link interfaces on multiple- | ||||
switching-capability LSRs can be advertised with multiple ISCDs). | ||||
This may lead to an increase in the amount of information that has | ||||
to be flooded and stored within the network. | ||||
Furthermore, path computation times, which may be of great importance | ||||
during restoration, will depend on the size of the TED. | ||||
Thus MRN/MLN routing mechanisms MUST be designed to scale well with | ||||
an increase of any of the following: | ||||
Thus MRN/MLN routing mechanisms MUST be designed to scale well with 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 information | Further, design of the routing protocols MUST NOT prevent TE | |||
filtering based on ISCDs. The path computation mechanism and the signaling | information filtering based on ISCDs. The path computation mechanism | |||
protocol SHOULD be able to operate on partial TE information. | and the signaling protocol SHOULD be able to operate on partial TE | |||
information. | ||||
Since TE Links can advertise multiple Interface Switching Capabilities (ISC), | Since TE Links can advertise multiple Interface Switching | |||
the number of links can be limited (by combination) by using specific | Capabilities (ISCs), the number of links can be limited (by | |||
topological maps referred to as VNT (Virtual Network Topologies). The | combination) by using specific topological maps referred to as VNT | |||
introduction of virtual topological maps leads us to consider the concept of | (Virtual Network Topologies). The introduction of virtual topological | |||
emulation of data plane overlays. | maps leads us to consider the concept of emulation of data plane | |||
overlays. | ||||
5.4.Stability | 5.4.Stability | |||
Path computation is dependent on the network topology and associated link state. | Path computation is dependent on the network topology and associated | |||
The path computation stability of an upper layer may be impaired if the VNT | link state. The path computation stability of an upper layer may be | |||
changes frequently and/or if the status and TE parameters (the TE metric, for | impaired if the VNT changes frequently and/or if the status and TE | |||
instance) of links in the VNT changes frequently. In this context, robustness of | parameters (the TE metric, for instance) of links in the VNT changes | |||
the VNT is defined as the capability to smooth changes that may occur and avoid | frequently. In this context, robustness of the VNT is defined as the | |||
their propagation into higher layers. Changes to the VNT may be caused by the | capability to smooth changes that may occur and avoid their | |||
creation, deletion, or modification of LSPs. | propagation into higher layers. Changes to the VNT may be caused by | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
Creation, deletion, and modification of LSPs MAY be triggered by adjacent layers | the creation, deletion, or modification of LSPs. | |||
or through operational actions to meet traffic demand changes, topology changes, | ||||
signaling requests from the upper layer, and network failures. Routing | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
robustness SHOULD be traded with adaptability with respect to the change of | Creation, deletion, and modification of LSPs MAY be triggered by | |||
incoming traffic requests. | adjacent layers or through operational actions to meet traffic demand | |||
changes, topology changes, signaling requests from the upper layer, | ||||
and network failures. Routing robustness SHOULD be traded 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, the upper- | When reconfiguring the VNT according to a change in traffic demand, | |||
layer LSP might be disrupted. Such disruption to the upper layers MUST be | the upper-layer LSP might be disrupted. Such disruption to the upper | |||
minimized. | layers MUST be minimized. | |||
When residual resource decreases to a certain level, some lower layer LSPs MAY | When residual resource decreases to a certain level, some lower layer | |||
be released according to local or network policies. There is a trade-off between | LSPs MAY be released according to local or network policies. There is | |||
minimizing the amount of resource reserved in the lower layer and disrupting | a trade-off between minimizing the amount of resource reserved in the | |||
higher layer traffic (i.e. moving the traffic to other TE-LSPs so that some LSPs | lower layer and disrupting higher layer traffic (i.e. moving the | |||
can be released). Such traffic disruption MAY be allowed, but MUST be under the | traffic to other TE-LSPs so that some LSPs can be released). Such | |||
control of policy that can be configured by the operator. Any repositioning of | traffic disruption MAY be allowed, but MUST be under the control of | |||
traffic MUST be as non-disruptive as possible (for example, using make-before- | policy that can be configured by the operator. Any repositioning of | |||
break). | traffic MUST be as non-disruptive as possible (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 that | TE-Link parameters SHOULD be inherited from the parameters of the LSP | |||
provides the TE-link, and so from the TE-links in the lower layer that are | that provides the TE-link, and so from the TE-links in the lower | |||
traversed by the LSP. | layer that are traversed by the LSP. | |||
These include: | These include: | |||
- Interface Switching Capability | - Interface Switching Capability | |||
- TE metric | - TE metric | |||
- Maximum LSP bandwidth per priority level | - Maximum LSP bandwidth per priority level | |||
- Unreserved bandwidth for all priority levels | - Unreserved bandwidth for all priority levels | |||
- Maximum Reservable bandwidth | - Maximum Reservable bandwidth | |||
- Protection attribute | - Protection attribute | |||
- Minimum LSP bandwidth (depending on the Switching Capability) | - Minimum LSP bandwidth (depending on the Switching Capability) | |||
- SRLG | - SRLG | |||
Inheritance rules MUST be applied based on specific policies. Particular | Inheritance rules MUST be applied based on specific policies. | |||
attention should be given to the inheritance of TE metric (which may be other | Particular attention should be given to the inheritance of TE metric | |||
than a strict sum of the metrics of the component TE links at the lower layer), | (which may be other than a strict sum of the metrics of the component | |||
protection attributes, and SRLG. | TE links at the lower layer), protection attributes, and SRLG. | |||
As described earlier, hiding the routes of the lower-layer LSPs may lose | As described earlier, hiding the routes of the lower-layer LSPs may | |||
important information necessary to make LSPs in the higher layer network | lose important information necessary to make LSPs in the higher layer | |||
reliable. SRLGs may be used to identify which lower-layer LSPs share the same | network reliable. SRLGs may be used to identify which lower-layer | |||
failure risk so that the potential risk of the VNT becoming disjoint can be | LSPs share the same failure risk so that the potential risk of the | |||
minimized, and so that resource disjoint protection paths can be set up in the | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
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. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | 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 boundaries when | Path computation MAY take into account LSP region and layer | |||
computing a path for an LSP. For example, path computation MAY restrict the path | boundaries when computing a path for an LSP. For example, path | |||
taken by an LSP to only the links whose interface switching capability is PSC. | computation MAY restrict the path taken by an LSP to only the links | |||
whose interface switching capability is PSC. | ||||
Interface switching capability is used as a constraint in path computation. For | Interface switching capability is used as a constraint in path | |||
example, a TDM-LSP is routed over the topology composed of TE links of the same | computation. For example, a TDM-LSP is routed over the topology | |||
TDM layer. In calculating the path for the LSP, the TED MAY be filtered to | composed of TE links of the same TDM layer. In calculating the path | |||
include only links where both end include requested LSP switching type. In this | for the LSP, the TED MAY be filtered to include only links where both | |||
way hierarchical routing is done by using a TED filtered with respect to | end include requested LSP switching type. In this way hierarchical | |||
switching capability (that is, with respect to particular layer). | routing is done by using a TED filtered with respect to switching | |||
capability (that is, with respect to particular layer). | ||||
If triggered signaling is allowed, the path computation mechanism MAY produce a | If triggered signaling is allowed, the path computation mechanism MAY | |||
route containing multiple layers/regions. The path is computed over the multiple | produce a route containing multiple layers/regions. The path is | |||
layers/regions even if the path is not "connected" in the same layer as the | computed over the multiple layers/regions even if the path is not | |||
endpoints of the path exist. Note that here we assume that triggered signaling | "connected" in the same layer as the endpoints of the path exist. | |||
will be invoked to make the path "connected", when the upper-layer signaling | Note that here we assume that triggered signaling will be invoked to | |||
request arrives at the boundary node. | make the path "connected", when the upper-layer signaling request | |||
arrives at the boundary node. | ||||
The upper-layer signaling request may contain an ERO that includes only hops in | The upper-layer signaling request may contain an ERO that includes | |||
the upper layer, in which case the boundary node is responsible for triggered | only hops in the upper layer, in which case the boundary node is | |||
creation of the lower-layer FA-LSP using a path of its choice, or for the | responsible for triggered creation of the lower-layer FA-LSP using a | |||
selection of any available lower layer LSP as a data link for the higher layer. | path of its choice, or for the selection of any available lower layer | |||
This mechanism is appropriate for environments where the TED is filtered in the | LSP as a data link for the higher layer. This mechanism is | |||
higher layer, where separate routing instances are used per layer, or where | appropriate for environments where the TED is filtered in the higher | |||
administrative policies prevent the higher layer from specifying paths through | layer, where separate routing instances are used per layer, or where | |||
the lower layer. | administrative policies prevent the higher layer from specifying | |||
paths through the lower layer. | ||||
Obviously, if the lower layer LSP has been advertised as a TE link (virtual or | Obviously, if the lower layer LSP has been advertised as a TE link | |||
real) into the higher layer, then the higher layer signaling request may contain | (virtual or real) into the higher layer, then the higher layer | |||
the TE link identifier and so indicate the lower layer resources to be used. But | signaling request may contain the TE link identifier and so indicate | |||
in this case, the path of the lower layer LSP can be dynamically changed by the | the lower layer resources to be used. But in this case, the path of | |||
lower layer at any time. | 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 specifying | Alternatively, the upper-layer signaling request may contain an ERO | |||
the lower layer FA-LSP route. In this case, the boundary node is responsible for | specifying the lower layer FA-LSP route. In this case, the boundary | |||
decision as to which it should use the path contained in the strict ERO or it | node is responsible for decision as to which it should use the path | |||
should re-compute the path within in the lower-layer. | contained in the strict ERO or it should re-compute the path within | |||
in the lower-layer. | ||||
Even in case the lower-layer FA-LSPs are already established, a signaling | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
request may also be encoded as loose ERO. In this situation, it is up to the | ||||
boundary node to decide whether it should a new lower-layer FA-LSP or it should | ||||
use the existing lower-layer FA-LSPs. | ||||
The lower-layer FA-LSP can be advertised just as an FA-LSP in the upper-layer or | Even in case the lower-layer FA-LSPs are already established, a | |||
an IGP adjacency can be brought up on the lower-layer FA-LSP. | signaling request may also be encoded as loose ERO. In this | |||
situation, it is up to the boundary node to decide whether it should | ||||
a new lower-layer FA-LSP or it should use the existing lower-layer | ||||
FA-LSPs. | ||||
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 | ||||
FA-LSP. | ||||
5.8. LSP Resource Utilization | 5.8. LSP Resource Utilization | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
It MUST be possible to utilize network resources efficiently. Particularly, | It MUST be possible to utilize network resources efficiently. | |||
resource usage in all layers SHOULD be optimized as a whole (i.e., across all | Particularly, resource usage in all layers SHOULD be optimized as a | |||
layers), in a coordinated manner, (i.e., taking all layers into account). The | whole (i.e., across all layers), in a coordinated manner, (i.e., | |||
number of lower-layer LSPs carrying upper-layer LSPs SHOULD be minimized (note | taking all layers into account). The number of lower-layer LSPs | |||
that multiple LSPs MAY be used for load balancing). Lower-layer LSPs that could | carrying upper-layer LSPs SHOULD be minimized (note that multiple | |||
have their traffic re-routed onto other LSPs are unnecessary and SHOULD be | LSPs MAY be used for load balancing). Lower-layer LSPs that could | |||
avoided. | have their traffic re-routed onto other LSPs are unnecessary and | |||
SHOULD be avoided. | ||||
5.8.1. FA-LSP Release and Setup | 5.8.1. FA-LSP Release and Setup | |||
Statistical multiplexing can only be employed in PSC and L2SC regions. A PSC or | Statistical multiplexing can only be employed in PSC and L2SC | |||
L2SC LSP may or may not consume the maximum reservable bandwidth of the TE link | regions. A PSC or L2SC LSP may or may not consume the maximum | |||
(FA LSP) that carries it. On the other hand, a TDM, or LSC LSP always consumes a | reservable bandwidth of the TE link (FA-LSP) that carries it. On the | |||
fixed amount of bandwidth as long as it exists (and is fully instantiated) | other hand, a TDM, or LSC LSP always consumes a fixed amount of | |||
because statistical multiplexing is not available. | bandwidth as long as it exists (and is fully instantiated) because | |||
statistical multiplexing is not available. | ||||
If there is low traffic demand, some FA LSPs that do not carry any higher-layer | If there is low traffic demand, some FA-LSPs that do not carry any | |||
LSP MAY be released so that lower-layer resources are released and can be | higher-layer LSP MAY be released so that lower-layer resources are | |||
assigned to other uses. Note that if a small fraction of the available bandwidth | released and can be assigned to other uses. Note that if a small | |||
of an FA-LSP is still in use, the nested LSPs can also be re-routed to other FA- | fraction of the available bandwidth of an FA-LSP is still in use, the | |||
LSPs (optionally using the make-before-break technique) to completely free up | nested LSPs can also be re-routed to other FA-LSPs (optionally using | |||
the FA-LSP. Alternatively, unused FA LSPs MAY be retained for future use. | the make-before-break technique) to completely free up the FA-LSP. | |||
Release or retention of underutilized FA LSPs is a policy decision. | Alternatively, unused FA-LSPs MAY be retained for future use. Release | |||
or retention of underutilized FA-LSPs is a policy decision. | ||||
As part of the re-optimization process, the solution MUST allow rerouting of an | As part of the re-optimization process, the solution MUST allow | |||
FA LSP while keeping interface identifiers of corresponding TE links unchanged. | rerouting of an FA-LSP while keeping interface identifiers of | |||
Further, this process MUST be possible while the FA LSP is carrying traffic | corresponding TE links unchanged. Further, this process MUST be | |||
(higher layer LSPs) with minimal disruption to the traffic. | possible while the FA-LSP is carrying traffic (higher layer LSPs) | |||
with minimal disruption to the traffic. | ||||
Additional FA LSPs MAY also be created based on policy, which might consider | Additional FA-LSPs MAY also be created based on policy, which might | |||
residual resources and the change of traffic demand across the region. By | consider residual resources and the change of traffic demand across | |||
creating the new FA LSPs, the network performance such as maximum residual | the region. By creating the new FA-LSPs, the network performance such | |||
capacity may increase. | as maximum residual capacity may increase. | |||
As the number of FA LSPs grows, the residual resource may decrease. In this case, | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
re-optimization of FA LSPs MAY be invoked according to policy. | ||||
Any solution MUST include measures to protect against network destabilization | As the number of FA-LSPs grows, the residual resource may decrease. | |||
caused by the rapid setup and teardown of LSPs as traffic demand varies near a | In this case, re-optimization of FA-LSPs MAY be invoked according to | |||
threshold. | policy. | |||
Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly advertise | Any solution MUST include measures to protect against network | |||
the LSP as a TE link and to coordinate into which routing instances the TE link | destabilization caused by the rapid setup and teardown of LSPs as | |||
should be advertised. | traffic demand varies near a threshold. | |||
Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly | ||||
advertise the LSP as a TE link and to coordinate into which routing | ||||
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-provision) | It may be considered disadvantageous to fully instantiate (i.e. pre- | |||
the set of lower layer LSPs that provide the VNT since this might reserve | provision) the set of lower layer LSPs that provide the VNT since | |||
bandwidth that could be used for other LSPs in the absence of upper-layer | this might reserve bandwidth that could be used for other LSPs in the | |||
traffic. | absence of upper-layer traffic. | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | However, in order to allow path computation of upper-layer LSPs | |||
across the lower-layer, the lower-layer LSPs MAY be advertised into | ||||
the upper-layer as though they had been fully established, but | ||||
without actually establishing them. Such TE links that represent the | ||||
possibility of an underlying LSP are termed "virtual TE-links." It is | ||||
an implementation choice at a layer boundary node whether to create | ||||
real or virtual TE-links, and the choice if available in an | ||||
implementation MUST be under the control of operator policy. Note | ||||
that there is no requirement to support the creation of virtual TE- | ||||
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 | ||||
higher layer, it is possible to route a higher layer LSP into a lower | ||||
layer on the assumptions that proper hierarchical LSPs in the lower | ||||
layer will be dynamically created (triggered) as needed. | ||||
However, in order to allow path computation of upper-layer LSPs across the | If an upper-layer LSP that makes use of a virtual TE-Link is set up, | |||
lower-layer, the lower-layer LSPs MAY be advertised into the upper-layer as | the underlying LSP MUST be immediately signaled in the lower layer. | |||
though they had been fully established, but without actually establishing them. | ||||
Such TE links that represent the possibility of an underlying LSP are termed | ||||
"virtual TE-links." It is an implementation choice at a layer boundary node | ||||
whether to create real or virtual TE-links, and the choice if available in an | ||||
implementation MUST be under the control of operator policy. Note that there is | ||||
no requirement to support the creation of virtual TE-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 higher layer, it is possible to route a higher layer | ||||
LSP into a lower layer on the assumptions that proper hierarchical LSPs in the | ||||
lower layer will be dynamically created (triggered) as needed. | ||||
If an upper-layer LSP that makes use of a virtual TE-Link is set up, the | If virtual TE-Links are used in place of pre-established LSPs, the | |||
underlying LSP MUST be immediately signaled in the lower layer. | TE-links across the upper-layer can remain stable using pre-computed | |||
paths while wastage of bandwidth within the lower-layer and | ||||
unnecessary reservation of adaptation ports at the border nodes can | ||||
be avoided. | ||||
If virtual TE-Links are used in place of pre-established LSPs, the TE-links | The solution SHOULD provide operations to facilitate the build-up of | |||
across the upper-layer can remain stable using pre-computed paths while wastage | such virtual TE-links, taking into account the (forecast) traffic | |||
of bandwidth within the lower-layer and unnecessary reservation of adaptation | demand and available resource in the lower-layer. | |||
ports at the border nodes can be avoided. | ||||
The solution SHOULD provide operations to facilitate the build-up of such | Virtual TE-links MAY be added, removed or modified dynamically (by | |||
virtual TE-links, taking into account the (forecast) traffic demand and | changing their capacity) according to the change of the (forecast) | |||
available resource in the lower-layer. | traffic demand and the available resource in the lower-layer. The | |||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
Virtual TE-links MAY be added, removed or modified dynamically (by changing | maximum number of virtual TE links that can be defined SHOULD be | |||
their capacity) according to the change of the (forecast) traffic demand and the | configurable. | |||
available resource in the lower-layer. The maximum number of virtual TE links | ||||
that can be defined SHOULD be configurable. | ||||
Any solution MUST include measures to protect against network destabilization | Any solution MUST include measures to protect against network | |||
caused by the rapid changes in the virtual network topology as traffic demand | destabilization caused by the rapid changes in the virtual network | |||
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 to form | The concept of the VNT can be extended to allow the virtual TE-links | |||
part of the VNT. The combination of the fully provisioned TE-links and the | to form part of the VNT. The combination of the fully provisioned TE- | |||
virtual TE-links defines the VNT provided by the lower layer. The VNT can be | links and the virtual TE-links defines the VNT provided by the lower | |||
changed by setting up and/or tearing down virtual TE links as well as by | layer. The VNT can be changed by setting up and/or tearing down | |||
modifying real links (i.e. the fully provisioned LSPs). How to design the VNT | virtual TE links as well as by modifying real links (i.e., the fully | |||
and how to manage it are out of scope of this document. | provisioned LSPs). How to design the VNT and how to manage it are out | |||
of scope of this document. | ||||
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 higher layer, | When a lower layer LSP is established for use as a data link by a | |||
the LSP MAY be verified for correct connectivity and data integrity. Such | higher layer, the LSP MAY be verified for correct connectivity and | |||
mechanisms are data technology-specific and are beyond the scope of this | data integrity. Such mechanisms are data technology-specific and are | |||
document, but may be coordinated through the GMPLS control plane. | beyond the scope of this document, but may be coordinated through the | |||
GMPLS control plane. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
6. Security Considerations | 6. Security Considerations | |||
The current version of this document does not introduce any new security | The MLN/MRN architecture does not introduce any new security | |||
considerations as it only lists a set of requirements. | requirements over the general GMPLS architecture described in | |||
[RFC3945]. Additional security considerations form MPLS and GMPLS | ||||
networks are described in [MPLS-SEC]. | ||||
It is expected that solution documents will include a full analysis of the | However, where the separate layers of a MLN/MRN network are operated | |||
security issues that any protocol extensions introduce. | as different administrative domains, additional security | |||
considerations may be given to the mechanisms for allowing inter- | ||||
layer LSP setup, for triggering lower-layer LSPs, or for VNT | ||||
management. Similarly, consideration may be given to the amount of | ||||
information shared between administrative domains, and the trade-off | ||||
between multi-layer TE and confidentiality of information belonging | ||||
to each administrative domain. | ||||
It is expected that solution documents will include a full analysis | ||||
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. References | 8. Acknowledgements | |||
8.1. Normative Reference | The authors would like to thank Adrian Farrel and the participants of | |||
ITU-T Study Group 15 Question 14 for their careful review. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
9. References | ||||
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] K.Kompella and Y.Rekhter, "Routing Extensions in Support of | [RFC4202] Kompella, K., and Rekhter, Y., "Routing Extensions in | |||
Generalized Multi-Protocol Label Switching (GMPLS)," RFC4202, | Support of Generalized Multi-Protocol Label Switching | |||
October 2005. | (GMPLS)," RFC4202, October 2005. | |||
[RFC4726] A.Farrel, J-P. Vasseur, and A.Ayyangar, "A Framework for Inter- | ||||
Domain Multiprotocol Label Switching Traffic Engineering", RFC | ||||
4726, November 2006. | ||||
[RFC4206] K.Kompella and Y.Rekhter, "Label Switched Paths (LSP) Hierarchy | [RFC4726] Farrel, A., Vasseur, JP., and Ayyangar, A., "A Framework | |||
with Generalized Multi-Protocol Label Switching (GMPLS) Traffic | for Inter-Domain Multiprotocol Label Switching Traffic | |||
Engineering (TE)," RFC4206, Oct. 2005. | Engineering", RFC 4726, November 2006. | |||
[RFC3945] E.Mannie (Ed.), "Generalized Multi-Protocol Label Switching | [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) | |||
(GMPLS) Architecture", RFC 3945, October 2004. | Hierarchy with Generalized Multi-Protocol Label Switching | |||
[RFC4397] I.Bryskin and A. Farrel, "A Lexicography for the Interpretation of | (GMPLS) Traffic Engineering (TE)," RFC4206, Oct. 2005. | |||
Generalized Multiprotocol Label Switching (GMPLS) | ||||
Terminology within the Context of the ITU-T's Automatically | ||||
Switched Optical Network (ASON) Architecture", RFC 4397, | ||||
February 2006. | ||||
8.2. Informative References | [RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Architecture", RFC 3945, October 2004. | ||||
[MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., Shiomoto, | [RFC4397] Bryskin, I., and Farrel, A., "A Lexicography for the | |||
K., Vigoureux, M.,"Evaluation of existing GMPLS Protocols | Interpretation of Generalized Multiprotocol Label Switching | |||
against Multi Layer and Multi Region Networks (MLN/MRN)", | (GMPLS) Terminology within the Context of the ITU-T's | |||
draft-ietf-ccamp-gmpls-mrn-eval, work in progress. | Automatically Switched Optical Network (ASON) | |||
Architecture", RFC 4397, February 2006. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | 9.2. Informative References | |||
[MPLS-GMPLS] K. Kumaki (Editor), "Interworking Requirements to Support | [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., | |||
operation of MPLS-TE over GMPLS networks", draft- | Shiomoto, K., Vigoureux, M., "Evaluation of Existing | |||
ietf-ccamp-mpls-gmpls-interwork-reqts, work in progress. | GMPLS Protocols Against Multi-Layer and Multi-Region | |||
Network (MLN/MRN) Requirements", draft-ietf-ccamp-gmpls- | ||||
mln-eval, work in progress. | ||||
[DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and Ali, Z., | [MPLS-GMPLS] K. Kumaki (Editor), "Interworking Requirements to | |||
"Procedures for Dynamically Signaled Hierarchical Label | Support Operation of MPLS-TE over GMPLS Networks", | |||
Switched Paths", draft-ietf-ccamp-lsp-hierarchy-bis, work in | draft-ietf-ccamp-mpls-gmpls-interwork-reqts, work in | |||
progress. | progress. | |||
[AUTO-MESH] Vasseur, JP., Le Roux, JL., et al., "Routing extensions for | [DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and | |||
discovery of Multiprotocol (MPLS) Label Switch Router (LSR) | Ali, Z., "Procedures for Dynamically Signaled | |||
Traffic Engineering (TE) mesh membership", draft-ietf-ccamp- | Hierarchical Label Switched Paths", draft-ietf-ccamp- | |||
automesh, work in progress. | lsp-hierarchy-bis, work in progress. | |||
9. Authors' Addresses | [MPLS-SEC] Fang, L., et al., " Security Framework for MPLS and | |||
GMPLS Networks", draft-fang-mpls-gmpls-security- | ||||
framework, work in progress. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | ||||
[RFC4972] Vasseur, JP., Le Roux, JL., et al., "Routing Extensions | ||||
for Discovery of Multiprotocol (MPLS) Label Switch | ||||
Router (LSR) Traffic Engineering (TE) Mesh Membership", | ||||
RFC 4972, July 2007. | ||||
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, | |||
skipping to change at page 20, line 4 | skipping to change at page 22, line 45 | |||
Route de Nozay, 91461 Marcoussis cedex, France | Route de Nozay, 91461 Marcoussis cedex, France | |||
Phone: +33 (0)1 69 63 18 52 | Phone: +33 (0)1 69 63 18 52 | |||
Email: martin.vigoureux@alcatel-lucent.fr | Email: martin.vigoureux@alcatel-lucent.fr | |||
Deborah Brungard | Deborah Brungard | |||
AT&T | AT&T | |||
Rm. D1-3C22 - 200 | Rm. D1-3C22 - 200 | |||
S. Laurel Ave., Middletown, NJ 07748, USA | S. Laurel Ave., Middletown, NJ 07748, USA | |||
Phone: +1 732 420 1573 | Phone: +1 732 420 1573 | |||
Email: dbrungard@att.com | Email: dbrungard@att.com | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
10.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, | |||
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 | |||
Emmanuel Dotaro | Emmanuel Dotaro | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Route de Nozay, | Route de Nozay, | |||
91461 Marcoussis cedex, | 91461 Marcoussis cedex, | |||
France | France | |||
Phone : +33 1 6963 4723 | Phone : +33 1 6963 4723 | |||
Email: emmanuel.dotaro@alcatel-lucent.fr | Email: emmanuel.dotaro@alcatel-lucent.fr | |||
11. Intellectual Property Considerations | 12. Intellectual Property Considerations | |||
The IETF takes no position regarding the validity or scope of any Intellectual | The IETF takes no position regarding the validity or scope of any | |||
Property Rights or other rights that might be claimed to pertain to the | Intellectual Property Rights or other rights that might be claimed to | |||
implementation or use of the technology described in this document or the extent | pertain to the implementation or use of the technology described in | |||
to which any license under such rights might or might not be available; nor does | this document or the extent to which any license under such rights | |||
it represent that it has made any independent effort to identify any such rights. | might or might not be available; nor does it represent that it has | |||
Information on the procedures with respect to rights in RFC documents can be | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any assurances of | Copies of IPR disclosures made to the IETF Secretariat and any | |||
licenses to be made available, or the result of an attempt made to obtain a | assurances of licenses to be made available, or the result of an | |||
general license or permission for the use of such proprietary rights by | attempt made to obtain a general license or permission for the use of | |||
implementers or users of this specification can be obtained from the IETF on- | such proprietary rights by implementers or users of this | |||
line IPR repository at http://www.ietf.org/ipr. | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any copyrights, | The IETF invites any interested party to bring to its attention any | |||
patents or patent applications, or other proprietary rights that may cover | copyrights, patents or patent applications, or other proprietary | |||
technology that may be required to implement this standard. Please address the | rights that may cover technology that may be required to implement | |||
information to the IETF at ietf-ipr@ietf.org. | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ||||
12. Full Copyright Statement | 13. Full Copyright Statement | |||
draft-ietf-ccamp-gmpls-mln-reqs-04.txt August 2007 | ||||
Copyright (C) The IETF Trust (2007). This document is subject to the rights, | Copyright (C) The IETF Trust (2007). | |||
licenses and restrictions contained in BCP 78, and except as set forth therein, | ||||
the authors retain all their rights. | ||||
This document and the information contained herein are provided on an "AS IS" | This document is subject to the rights, licenses and restrictions | |||
basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY | contained in BCP 78, and except as set forth therein, the authors | |||
(IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING | retain all their rights. | |||
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT | ||||
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE | draft-ietf-ccamp-gmpls-mln-reqs-05.txt August 2007 | |||
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A | ||||
PARTICULAR PURPOSE. | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST | ||||
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | ||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | ||||
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY | ||||
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR | ||||
PURPOSE. | ||||
End of changes. 160 change blocks. | ||||
717 lines changed or deleted | 860 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/ |