draft-ietf-ccamp-gmpls-mln-reqs-00.txt | draft-ietf-ccamp-gmpls-mln-reqs-01.txt | |||
---|---|---|---|---|
Network Working Group Kohei Shiomoto (NTT) | Network Working Group Kohei Shiomoto (NTT) | |||
Internet Draft Dimitri Papadimitriou (Alcatel) | Internet Draft Dimitri Papadimitriou (Alcatel) | |||
Jean-Louis Le Roux (France Telecom) | Jean-Louis Le Roux (France Telecom) | |||
Martin Vigoureux (Alcatel) | Martin Vigoureux (Alcatel) | |||
Deborah Brungard (AT&T) | Deborah Brungard (AT&T) | |||
Expires: July 2006 January 2006 | ||||
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-00.txt | draft-ietf-ccamp-gmpls-mln-reqs-01.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
This document may only be posted in an Internet-Draft. | This document may only be posted in an Internet-Draft. | |||
skipping to change at page 1, line 42 | skipping to change at page 1, line 39 | |||
documents at any time. It is inappropriate to use Internet-Drafts | documents at any time. It is inappropriate to use Internet-Drafts | |||
as reference material or to cite them other than as "work in | as reference material or to cite them other than as "work in | |||
progress." | progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
This Internet-Draft will expire on July 2006. | This Internet-Draft will expire on December 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
Most of the initial efforts on Generalized MPLS (GMPLS) have been | Most of the initial efforts on Generalized MPLS (GMPLS) have been | |||
related to environments hosting devices with a single switching | related to environments hosting devices with a single switching | |||
capability. The complexity raised by the control of such data | capability. The complexity raised by the control of such data | |||
planes is similar to that seen in classical IP/MPLS networks. | planes is similar to that seen in classical IP/MPLS networks. | |||
By extending MPLS to support multiple switching technologies, GMPLS | By extending MPLS to support multiple switching technologies, GMPLS | |||
provides a comprehensive framework for the control of a multi- | provides a comprehensive framework for the control of a multi- | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
layered network of either a single switching technology or multiple | layered network of either a single switching technology or multiple | |||
switching technologies. In GMPLS, a switching technology domain | switching technologies. In GMPLS, a switching technology domain | |||
defines a region, and a network of multiple switching types is | defines a region, and a network of multiple switching types is | |||
referenced in this document as a multi-region network (MRN). When | referenced in this document as a multi-region network (MRN). When | |||
referring in general to a layered network, which may consist of | referring in general to a layered network, which may consist of | |||
either a single or multiple regions, this document uses the term, | either a single or multiple regions, this document uses the term, | |||
Multi-layer Network (MLN). This draft defines a framework for GMPLS | Multi-layer Network (MLN). This draft defines a framework for GMPLS | |||
based multi-region/multi-layer networks and lists a set of | based multi-region/multi-layer networks and lists a set of | |||
functional requirements. | functional requirements. | |||
Table of Contents | Table of Contents | |||
1. Introduction...................................................2 | 1. Introduction...................................................2 | |||
2. Conventions used in this document..............................4 | 2. Conventions used in this document..............................4 | |||
3. Positioning....................................................4 | 3. Positioning....................................................4 | |||
3.1. Data plane layers and control plane regions..................5 | 3.1. Data plane layers and control plane regions..................5 | |||
3.2. Services.....................................................5 | 3.2. Service layer networks.......................................5 | |||
3.3. Vertical and Horizontal interaction and integration..........6 | 3.3. Vertical and Horizontal interaction and integration..........6 | |||
4. Key concepts of GMPLS-based MLNs and MRNs......................6 | 4. Key concepts of GMPLS-based MLNs and MRNs......................7 | |||
4.1. Interface Switching Capability...............................7 | 4.1. Interface Switching Capability...............................7 | |||
4.2. Multiple Interface Switching Capabilities....................7 | 4.2. Multiple Interface Switching Capabilities....................8 | |||
4.2.1. Networks with multi-switching capable hybrid nodes.........8 | 4.2.1. Networks with multi-switching-type-capable hybrid nodes....8 | |||
4.3. Integrated Traffic Engineering (TE) and Resource Control.....9 | 4.3. Integrated Traffic Engineering (TE) and Resource Control.....9 | |||
4.3.1. Triggered signaling........................................9 | 4.3.1. Triggered signaling.......................................10 | |||
4.3.2. FA-LSP....................................................10 | 4.3.2. FA-LSP....................................................10 | |||
4.3.3. Virtual network topology (VNT)............................10 | 4.3.3. Virtual network topology (VNT)............................11 | |||
5. Service networks provided over MRN/MLN........................11 | 5. Requirements..................................................11 | |||
6. Requirements..................................................11 | 5.1. Scalability.................................................11 | |||
6.1. Scalability.................................................11 | 5.2. LSP resource utilization....................................12 | |||
6.2. LSP resource utilization....................................12 | 5.2.1. FA-LSP release and setup..................................12 | |||
6.2.1. FA-LSP release and setup..................................12 | 5.2.2. Virtual TE-Link...........................................13 | |||
6.2.2. Virtual TE-Link...........................................12 | 5.3. LSP Attribute inheritance...................................14 | |||
6.3. LSP Attribute inheritance...................................14 | 5.4. Verification of the LSP.....................................14 | |||
6.4. Verification of the LSP.....................................14 | 5.5. Disruption minimization.....................................14 | |||
6.5. Disruption minimization.....................................14 | 5.6. Stability...................................................15 | |||
6.6. Stability...................................................14 | 5.7. Computing paths with and without nested signaling...........16 | |||
6.7. Computing paths with and without nested signaling...........15 | 5.8. Handling single-switching and multi-switching-type-capable | |||
6.8. Handling single-switching and multi-switching type capable | nodes............................................................17 | |||
nodes............................................................16 | 5.9. Advertisement of the available adaptation resource..........17 | |||
6.9. Advertisement of the available adaptation resource..........16 | 6. Security Considerations.......................................17 | |||
7. Security Considerations.......................................17 | 7. References....................................................18 | |||
8. References....................................................17 | 7.1. Normative Reference.........................................18 | |||
8.1. Normative Reference.........................................17 | 7.2. Informative References......................................18 | |||
8.2. Informative References......................................18 | 8. Author's Addresses............................................19 | |||
9. Author's Addresses............................................18 | 9. Intellectual Property Considerations..........................20 | |||
10. Intellectual Property Considerations.........................19 | 10. Full Copyright Statement.....................................20 | |||
11. Full Copyright Statement.....................................20 | ||||
1. Introduction | 1. Introduction | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
Generalized MPLS (GMPLS) extends MPLS to handle multiple switching | Generalized MPLS (GMPLS) extends MPLS to handle multiple switching | |||
technologies: packet switching, layer-two switching, TDM switching, | technologies: packet switching, layer-two switching, TDM switching, | |||
wavelength switching, and fiber switching (see [RFC3945]). The | wavelength switching, and fiber switching (see [RFC3945]). The | |||
Interface Switching Capability (ISC) concept is introduced for | Interface Switching Capability (ISC) concept is introduced for | |||
these switching technologies and is designated as follows: PSC | these switching technologies and is designated as follows: PSC | |||
(packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | (packet switch capable), L2SC (Layer-2 switch capable), TDM (Time | |||
Division Multiplex capable), LSC (lambda switch capable), and FSC | Division Multiplex capable), LSC (lambda switch capable), and FSC | |||
(fiber switch capable). | (fiber switch capable). | |||
Service providers may operate networks where multiple different | Service providers may operate networks where multiple different | |||
switching technologies exist. The representation, in a GMPLS | switching technologies exist. The representation, in a GMPLS | |||
control plane, of a switching technology domain is referred to as a | control plane, of a switching technology domain is referred to as a | |||
region [HIER]. | region [RFC4206]. | |||
A switching type describes the ability of a node to forward data of | A switching type describes the ability of a node to forward data of | |||
a particular data plane technology, and uniquely identifies a | a particular data plane technology, and uniquely identifies a | |||
network region. A layer describes a data plane switching | network region. A layer describes a data plane switching | |||
granularity level (e.g. VC4, VC-12). A data plane layer is | granularity level (e.g. VC4, VC-12). A data plane layer is | |||
associated with a region in the control plane (e.g. VC4 associated | associated with a region in the control plane (e.g. VC4 associated | |||
to TDM, IP associated to PSC). However, more than one data plane | to TDM, IP associated to PSC). However, more than one data plane | |||
layer can be associated to the same region (e.g. both VC4 and VC12 | layer can be associated to the same region (e.g. both VC4 and VC12 | |||
are associated to TDM). Thus, a control plane region, identified by | are associated to TDM). Thus, a control plane region, identified by | |||
its switching type value (e.g. TDM), can itself be sub-divided into | its switching type value (e.g. TDM), can itself be sub-divided into | |||
smaller granularity based on the bandwidth that defines the "data | smaller granularity based on the bandwidth that defines the "data | |||
plane switching layers" e.g. from VC-11 to VC4-256c. The Interface | plane switching layers" e.g. from VC-11 to VC4-256c. The Interface | |||
Switching Capability Descriptor (ISCD) [GMPLS-RTG], identifying the | Switching Capability Descriptor (ISCD) [RFC4202], identifying the | |||
interface switching type, the encoding type and the switching | interface switching type, the encoding type and the switching | |||
bandwidth granularity, enable the characterization of the | bandwidth granularity, enable the characterization of the | |||
associated layers. | associated layers. | |||
A network comprising transport nodes with multiple data plane | A network comprising transport nodes with multiple data plane | |||
layers of either the same ISC or different ISCs, controlled by a | layers of either the same ISC or different ISCs, controlled by a | |||
single GMPLS control plane instance, is called a Multi-Layer | single GMPLS control plane instance is called a Multi-Layer Network | |||
Network (MLN). To differentiate a network supporting LSPs of | (MLN). To differentiate a network supporting LSPs of different | |||
different switching technologies (ISCs) from a single region | switching technologies (ISCs) from a single region network, a | |||
network, a network supporting more than one switching technology is | network supporting more than one switching technology is called a | |||
called a Multi-Region Network (MRN). | Multi-Region Network (MRN). All MRNs are MLNs, by definition. | |||
MRNs can be categorized according to the distribution of the | ||||
switching type values amongst the LSRs: | ||||
- Network elements are single switching capable LSRs and | ||||
different types of LSRs form the network. | ||||
- Network elements are multi-switching capable LSRs i.e. nodes | ||||
hosting at least more than one switching capability. Multi- | ||||
switching capable LSRs are further | ||||
classified as "simplex" and "hybrid" nodes (see Section 4.2). | ||||
- Any combination of the above two elements. A network composed | ||||
of both single and multi-switching capable LSRs. | ||||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | MLNs can be categorized according to the distribution of the ISCD | |||
values amongst the LSRs: | ||||
- Each LSR may support just one ISCD, and the MLN may be comprised | ||||
of LSRs that support different ISCDs. Such LSRs are known as | ||||
single-switching-type-capable LSRs. | ||||
- Each LSR may support more than one ISCD at the same time so that | ||||
the network containing these LSR is an MLN. Such LSRs are known | ||||
as multi-switching-type-capable LSRs, and can be further | ||||
classified as either "simplex" or "hybrid" nodes as defined in | ||||
Section 4.2. | ||||
- The MLN may be constructed from any combination of single- | ||||
switching-type-capable LSRs and multi-switching-type-capable | ||||
LSRs. | ||||
Since GMPLS provides a comprehensive framework for the control of | Since GMPLS provides a comprehensive framework for the control of | |||
different switching capabilities, a single GMPLS instance may be | different switching capabilities, a single GMPLS instance may be | |||
used to control the MRNs/MLNs enabling rapid service provisioning | used to control the MLN enabling rapid service provisioning and | |||
and efficient traffic engineering across all switching capabilities. | efficient traffic engineering across all switching capabilities. In | |||
In such networks, TE Links are consolidated into a single Traffic | such networks, TE Links are consolidated into a single Traffic | |||
Engineering Database (TED). Since this TED contains the information | Engineering Database (TED). Since this TED contains the information | |||
relative to all the different regions/layers existing in the | relative to all the different regions and layers existing in the | |||
network, a path across multiple regions/layers can be computed | network, a path across multiple regions or layers can be computed | |||
using this TED. Thus optimization of network resources can be | using this TED. Thus optimization of network resources can be | |||
achieved across multiple regions/layers. | achieved across the whole MLN. | |||
Consider, for example, a MRN consisting of IP/MPLS routers and TDM | Consider, for example, a MRN consisting of packet-switch capable | |||
cross-connects. Assume that a packet LSP is routed between source | routers and TDM cross-connects. Assume that a packet LSP is routed | |||
and destination IP/MPLS routers, and that the LSP can be routed | between source and destination packet-switchi capable routers, and | |||
across the PSC-region (i.e. utilizing only resources of the IP/MPLS | that the LSP can be routed across the PSC-region (i.e. utilizing | |||
level topology). If the performance objective for the LSP is not | only resources of the packet region topology). If the performance | |||
satisfied, new TE links may be created between the IP/MPLS routers | objective for the LSP is not satisfied, new TE links may be created | |||
across the TDM-region (for example, VC-12 links) and the LSP can be | between the packet-switch capable routers across the TDM-region | |||
routed over those links. Further, even if the LSP can be | (for example, VC-12 links) and the LSP can be routed over those TE | |||
successfully established across the PSC-region, TDM hierarchical | links. Further, even if the LSP can be successfully established | |||
LSPs across the TDM region between the IP/MPLS routers may be | across the PSC-region, TDM hierarchical LSPs across the TDM region | |||
established and used if doing so enables meeting an operator's | between the packet-switch capable routers may be established and | |||
objectives on network resources available (e.g. link bandwidth, and | used if doing so is necessary to meet the operator's objectives for | |||
adaptation port between regions) across the multiple regions. The | network resources availability (e.g., link bandwidth, or adaptation | |||
same considerations hold when VC4 LSPs are provisioned to provide | ports between regions) across the regions. The same considerations | |||
extra flexibility for the VC12 and/or VC11 layers in a MLN. | 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- | This document describes the requirements to support multi- | |||
region/multi-layer networks. There is no intention to specify | region/multi-layer networks. There is no intention to specify | |||
solution specific elements in this document. The applicability of | solution-specific elements in this document. The applicability of | |||
existing GMPLS protocols and any protocol extensions to the MRN/MLN | existing GMPLS protocols and any protocol extensions to the MRN/MLN | |||
will be addressed in separate documents [MRN-EVAL]. | will be addressed in separate documents [MRN-EVAL]. | |||
2. Conventions used in this document | 2. Conventions used in this document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | |||
this document are to be interpreted as described in RFC 2119 | this document are to be interpreted as described in RFC 2119 | |||
[RFC2119]. | [RFC2119]. | |||
skipping to change at page 4, line 53 | skipping to change at page 5, line 4 | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | |||
this document are to be interpreted as described in RFC 2119 | this document are to be interpreted as described in RFC 2119 | |||
[RFC2119]. | [RFC2119]. | |||
3. Positioning | 3. Positioning | |||
A multi-region network (MRN) is always a multi-layer network (MLN) | A multi-region network (MRN) is always a multi-layer network (MLN) | |||
since the network devices on region boundaries bring together | since the network devices on region boundaries bring together | |||
different ISCs. A MLN, however, is not necessarily a MRN since | different ISCs. A MLN, however, is not necessarily a MRN since | |||
multiple layers could be fully contained within a single region. | multiple layers could be fully contained within a single region. | |||
For example, VC12, VC4, and VC4-4c are different layers of the TDM | For example, VC12, VC4, and VC4-4c are different layers of the TDM | |||
region. | region. | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
3.1. Data plane layers and control plane regions | 3.1. Data plane layers and control plane regions | |||
A data plane layer is a collection of network resources capable of | A data plane layer is a collection of network resources capable of | |||
terminating and/or switching data traffic of a particular format. | terminating and/or switching data traffic of a particular format. | |||
These resources can be used for establishing LSPs or connectionless | These resources can be used for establishing LSPs or connectionless | |||
traffic delivery. For example, VC-11 and VC4-64c represent two | traffic delivery. For example, VC-11 and VC4-64c represent two | |||
different layers. | different layers. | |||
From the control plane viewpoint, an LSP region is defined as a set | From the control plane viewpoint, an LSP region is defined as a set | |||
of one or several data plane layers that share the same type of | of one or more data plane layers that share the same type of | |||
switching technology, that is, the same switching type. The | switching technology, that is, the same switching type. For example, | |||
VC-11 and VC-4 layers are part of the same TDM region. The | ||||
currently defined regions are: PSC, L2SC, TDM, LSC, and FSC regions. | currently defined regions are: PSC, L2SC, TDM, LSC, and FSC regions. | |||
Hence, an LSP region is a technology domain (identified by the ISC | Hence, an LSP region is a technology domain (identified by the ISC | |||
type) for which data plane resources (i.e. data links) are | type) for which data plane resources (i.e. data links) are | |||
represented into the control plane as an aggregate of TE | represented into the control plane as an aggregate of TE | |||
information associated with a set of links (i.e. TE links). For | information associated with a set of links (i.e. TE links). For | |||
example VC-11 and VC4-64c capable TE links are part of the same TDM | example VC-11 and VC4-64c capable TE links are part of the same TDM | |||
region. Multiple layers can thus exist in a single region network. | region. Multiple layers can thus exist in a single region network. | |||
Note also that the region is a control plane only concept. That is, | Note also that the region may produce a distinction within the | |||
layers of the same region share the same switching technology and, | control plane. Layers of the same region share the same switching | |||
therefore, need the same set of technology specific signaling | technology and, therefore, use the same set of technology-specific | |||
objects. | signaling objects within the control plane, but layers from | |||
different regions may use different technology-specific objects or | ||||
encodings. This means that there is a control plane discontinuity | ||||
when crossing a region boundary. | ||||
3.2. Services | 3.2. Service layer networks | |||
A service provider's network may be divided into different service | A service provider's network may be divided into different service | |||
layers. The customer's network is considered from the provider's | layers. The customer's network is considered from the provider's | |||
perspective as the highest service layer. It interfaces to the | perspective as the highest service layer. It interfaces to the | |||
highest service layer of the service provider's network. | highest service layer of the service provider's network. | |||
Connectivity across the highest service layer of the service | Connectivity across the highest service layer of the service | |||
provider's network may be provided with support from successively | provider's network may be provided with support from successively | |||
lower service layers. Service layers are realized via a hierarchy | lower service layers. Service layers are realized via a hierarchy | |||
of network layers located generally in several regions and commonly | of network layers located generally in several regions and commonly | |||
arranged according to the switching capabilities of network devices. | arranged according to the switching capabilities of network devices. | |||
For instance some customers purchase Layer 1 (i.e. transport) | For instance some customers purchase Layer 1 (i.e. transport) | |||
services from the service provider, some Layer 2 (e.g. ATM), while | services from the service provider, some Layer 2 (e.g. ATM), while | |||
others purchase Layer 3 (IP/MPLS) services. The service provider | others purchase Layer 3 (IP/MPLS) services. The service provider | |||
realizes the services by a stack of network layers located within | realizes the services by a stack of network layers located within | |||
one or more network regions. The network layers are commonly | one or more network regions. The network layers are commonly | |||
arranged according to the switching capabilities of the devices in | arranged according to the switching capabilities of the devices in | |||
the networks. Thus, a customer network may be provided on top of | the networks. Thus, a customer network may be provided on top of | |||
the GMPLS-based multi-region/multi-layer network. For example, a | the GMPLS-based multi-region/multi-layer network. For example, a | |||
Layer One service (realized via the network layers of TDM, and/or | Layer 1 service (realized via the network layers of TDM, and/or LSC, | |||
LSC, and/or FSC regions) may support a Layer Two network (realized | and/or FSC regions) may support a Layer 2 network (realized via ATM | |||
via ATM VP/VC) which may itself support a Layer Three network | VP/VC) which may itself support a Layer 3 network (IP/MPLS region). | |||
(IP/MPLS region). The supported data plane relationship is a data- | The supported data plane relationship is a data-plane client-server | |||
plane client-server relationship where the lower layer provides a | relationship where the lower layer provides a service for the | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | higher layer using the data links realized in the lower layer. | |||
service for the higher layer using the data links realized in the | ||||
lower layer. | ||||
Services provided by a GMPLS-based multi-region/multi-layer network | Services provided by a GMPLS-based multi-region/multi-layer network | |||
are referred to as "Multi-region/Multi-layer network services". For | are referred to as "Multi-region/Multi-layer network services". For | |||
example legacy IP and IP/MPLS networks can be supported on top of | example, legacy IP and IP/MPLS networks can be supported on top of | |||
multi-region/multi-layer networks. It has to be emphasized that | multi-region/multi-layer networks. It has to be emphasized that | |||
delivery of such diverse services is a strong motivator for the | delivery of such diverse services is a strong motivator for the | |||
deployment of multi-region/multi-layer networks. | deployment of multi-region/multi-layer networks. | |||
A customer network may be provided on top of a server GMPLS-based | ||||
MRN/MLN which is operated by a service provider. For example, a | ||||
pure IP and/or an IP/MPLS network can be provided on top of GMPLS- | ||||
based packet over optical networks [IW-MIG-FW]. The relationship | ||||
between the networks is a client/server relationship and, such | ||||
services are referred to as "MRN/MLN services". In this case, the | ||||
customer network may form part of the MRN/MLN, or may be partially | ||||
separated, for 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 | Vertical interaction is defined as the collaborative mechanisms | |||
within a network element that is capable of supporting more than | within a network element that is capable of supporting more than | |||
one switching capability and of realizing the client/server | one layer and of realizing the client/server relationships between | |||
relationships between them. Protocol exchanges between two network | them. Protocol exchanges between two network controllers managing | |||
controllers managing different regions are also a vertical | different regions or layers are also a vertical interaction. | |||
interaction. Integration of these interactions as part of the | Integration of these interactions as part of the control plane is | |||
control plane is referred to as vertical integration. The latter | referred to as vertical integration. Thus, this refers thus to the | |||
refers thus to the collaborative mechanisms within a single control | collaborative mechanisms within a single control plane instance | |||
plane instance driving multiple switching capabilities. Such a | driving multiple network layers. Such a concept is useful in order | |||
concept is useful in order to construct a framework that | to construct a framework that facilitates efficient network | |||
facilitates efficient network resource usage and rapid service | resource usage and rapid service provisioning in carrier's networks | |||
provisioning in carrier's networks that are based on multiple | that are based on multiple layers, switching technologies, or ISCDs. | |||
switching technologies. | ||||
In a strict sense, horizontal interaction is defined as the | Horizontal interaction is defined as the protocol exchange between | |||
protocol exchange between network controllers that manage transport | network controllers that manage transport nodes within a given | |||
nodes within a given region (i.e. nodes with the same switching | layer or region (i.e. nodes with the same switching capability). | |||
capability). For instance, the control plane interaction between | For instance, the control plane interaction between two TDM network | |||
two LSC network elements is an example of horizontal interaction. | elements switching at OC-48 is an example of horizontal interaction. | |||
GMPLS protocol operations handle horizontal interactions within the | GMPLS protocol operations handle horizontal interactions within the | |||
same routing area. The case where the interaction takes place | same routing area. The case where the interaction takes place | |||
across a domain boundary, such as between two routing areas within | across a domain boundary, such as between two routing areas within | |||
the same network layer, is currently being evaluated as part of the | the same network layer, is currently being evaluated as part of the | |||
inter-domain work [Inter-domain], and is referred to as horizontal | inter-domain work [Inter-domain], and is referred to as horizontal | |||
integration. Thus horizontal integration refers to the | integration. Thus horizontal integration refers to the | |||
collaborative mechanisms between network partitions and/or | collaborative mechanisms between network partitions and/or | |||
administrative divisions such as routing areas or autonomous | administrative divisions such as routing areas or autonomous | |||
systems. This distinction gets blurred when administrative domains | systems. | |||
match layer boundaries. Horizontal interaction is extended to cover | ||||
such case. For example, the collaborative mechanisms in place | This distinction needs further clarification when administrative | |||
between two lambda switching capable areas relate to horizontal | domains match layer boundaries. Horizontal interaction is extended | |||
integration. On the other hand, the collaborative mechanisms in | to cover such cases. For example, the collaborative mechanisms in | |||
place in a network that supports IP/MPLS over TDM switching could | place between two lambda switching capable areas relate to | |||
be described as vertical and horizontal integration in the case | horizontal integration. On the other hand, the collaborative | |||
where each network belongs to a separate area. | mechanisms in place in a network that supports IP/MPLS over TDM | |||
switching could be described as vertical and horizontal integration | ||||
in the case where each network belongs to a separate routing area. | ||||
4. Key concepts of GMPLS-based MLNs and MRNs | 4. Key concepts of GMPLS-based MLNs and MRNs | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
A network comprising transport nodes with multiple data plane | A network comprising transport nodes with multiple data plane | |||
layers of either the same ISC or different ISCs, controlled by a | layers of either the same ISC or different ISCs, controlled by a | |||
single GMPLS control plane instance, is called a Multi-Layer | single GMPLS control plane instance, is called a Multi-Layer | |||
Network (MLN). A sub-set of MLNs consists of networks supporting | Network (MLN). A sub-set of MLNs consists of networks supporting | |||
LSPs of different switching technologies (ISCs). A network | LSPs of different switching technologies (ISCs). A network | |||
supporting more than one switching technology is called a Multi- | supporting more than one switching technology is called a Multi- | |||
Region Network (MRN). | Region Network (MRN). | |||
4.1. Interface Switching Capability | 4.1. Interface Switching Capability | |||
The Interface Switching Capability (ISC) is introduced in GMPLS to | The Interface Switching Capability (ISC) is introduced in GMPLS to | |||
support various kinds of switching technology in a unified way | support various kinds of switching technology in a unified way | |||
[GMPLS-ROUTING]. An ISC is identified via a switching type. | [RFC4202]. An ISC is identified via a switching type. | |||
A switching type (also referred to as the switching capability | A switching type (also referred to as the switching capability | |||
types) describes the ability of a node to forward data of a | type) describes the ability of a node to forward data of a | |||
particular data plane technology, and uniquely identifies a network | particular data plane technology, and uniquely identifies a network | |||
region. The following ISC types (and, hence, regions) are defined: | region. The following ISC types (and, hence, regions) are defined: | |||
PSC, L2SC, TDM, LSC, and FSC. Each end of a data link (more | PSC, L2SC, TDM, LSC, and FSC. Each end of a data link (more | |||
precisely, each interface connecting a data link to a node) in a | precisely, each interface connecting a data link to a node) in a | |||
GMPLS network is associated with an ISC. | GMPLS network is associated with an ISC. | |||
The ISC value is advertised as a part of the Interface Switching | The ISC value is advertised as a part of the Interface Switching | |||
Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end | Capability Descriptor (ISCD) attribute (sub-TLV) of a TE link end | |||
associated with a particular link interface. Apart from the ISC, | associated with a particular link interface [RFC4202]. Apart from | |||
the ISCD contains information, such as the encoding type, the | the ISC, the ISCD contains information, including the encoding type, | |||
bandwidth granularity, and the unreserved bandwidth on each of | the bandwidth granularity, and the unreserved bandwidth on each of | |||
eight priorities at which LSPs can be established. The ISCD does | eight priorities at which LSPs can be established. The ISCD does | |||
not "identify" network layers, it uniquely characterizes | not "identify" network layers, it uniquely characterizes | |||
information associated to one or more network layers. | information associated to one or more network layers. | |||
TE link end advertisements may contain multiple ISCDs. This can be | TE link end advertisements may contain multiple ISCDs. This can be | |||
interpreted as advertising a multi-layer (or multi-switching) TE | interpreted as advertising a multi-layer (or multi-switching) TE | |||
link end. | link end. That is, the TE link end is present in multiple layers. | |||
4.2. Multiple Interface Switching Capabilities | 4.2. Multiple Interface Switching Capabilities | |||
In a MLN, network elements may be single-switching or multi- | In an MLN, network elements may be single-switching or multi- | |||
switching type capable nodes. Single-switching type capable nodes | switching-type-capable nodes. Single-switching type capable nodes | |||
advertise the same ISC value as part of their ISCD sub-TLV(s) to | advertise the same ISC value as part of their ISCD sub-TLV(s) to | |||
describe the termination capabilities of their TE Link(s). This | describe the termination capabilities of their TE Link(s). This | |||
case is described in [GMPLS-ROUTING]. | case is described in [RFC4202]. | |||
Multi-switching capable LSRs are classified as "simplex" and | Multi-switching-type-capable LSRs are classified as "simplex" or | |||
"hybrid" nodes. Simplex and Hybrid nodes are categorized according | "hybrid" nodes. Simplex and hybrid nodes are categorized according | |||
to the way they advertise these multiple ISCs: | to the way they advertise these multiple ISCs: | |||
- A simplex node can terminate links with different switching | - A simplex node can terminate links with different switching | |||
capabilities each of them connected to the node by a single link | capabilities each of them connected to the node by a single link | |||
interface. So, it advertises several TE Links each with a single | interface. So, it advertises several TE Links each with a single | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
ISC value as part of its ISCD sub-TLVs. For example, an LSR with | ISC value as part of its ISCD sub-TLVs. For example, an LSR with | |||
PSC and TDM links each of which is connected to the LSR via single | PSC and TDM links each of which is connected to the LSR via single | |||
interface. | interface. | |||
- A hybrid node can terminate links with different switching | - A hybrid node can terminate links with different switching | |||
capabilities terminating on the same interface. So, it advertises | capabilities terminating on the same interface. So, it advertises | |||
at least one TE Link containing more than one ISCDs with different | at least one TE Link containing more than one ISCDs with different | |||
ISC values. For example, a node comprising of PSC and TDM links, | ISC values. For example, a node comprising of PSC and TDM links, | |||
which are interconnected via internal links. The external | which are interconnected via internal links. The external | |||
interfaces connected to the node have both PSC and TDM capability. | interfaces connected to the node have both PSC and TDM capability. | |||
Additionally TE link advertisements issued by a simplex or a hybrid | Additionally TE link advertisements issued by a simplex or a hybrid | |||
node may need to provide information about the node's internal | node may need to provide information about the node's internal | |||
adaptation capabilities between the switching technologies | adaptation capabilities between the switching technologies | |||
supported. That is, the node's capability to perform layer border | supported. That is, the node's capability to perform layer border | |||
node functions. | node functions. | |||
4.2.1. Networks with multi-switching capable hybrid nodes | 4.2.1. Networks with multi-switching-type-capable hybrid nodes | |||
The network contains at least one hybrid node, zero or more simplex | The network contains at least one hybrid node, zero or more simplex | |||
nodes, and a set of single switching capable nodes. | nodes, and a set of single-switching-type-capable nodes. | |||
Figure 5a shows an example hybrid node. The hybrid node has two | Figure 5a shows an example hybrid node. The hybrid node has two | |||
switching elements (matrices), which support, for instance, TDM and | switching elements (matrices), which support, for instance, TDM and | |||
PSC switching respectively. The node terminates two PSC and TDM | PSC switching respectively. The node terminates a PSC and a TDM | |||
links (Link1 and Link2 respectively). It also has internal link | link (Link1 and Link2 respectively). It also has an internal link | |||
connecting the two swtching elements. | connecting the two swtching elements. | |||
The two switching elements are internally interconnected in such a | The two switching elements are internally interconnected in such a | |||
way that it is possible to terminate some of the resources of, say, | way that it is possible to terminate some of the resources of, say, | |||
Link2 and provide through them adaptation for PSC traffic | Link2 and provide adaptation for PSC traffic received/sent over the | |||
received/sent over the PSC interface (#b). This situation is | PSC interface (#b). This situation is modeled in GMPLS by | |||
modeled in GMPLS by connecting the local end of Link2 to the TDM | connecting the local end of Link2 to the TDM switching element via | |||
switching element via an additional interface realizing the | an additional interface realizing the termination/adaptation | |||
termination/adaptation function. Two ways are possible to set up | function. Two ways are possible to set up PSC LSPs. Available | |||
PSC LSPs. Available resource advertisement e.g. Unreserved and | resource advertisement e.g. Unreserved and Min/Max LSP Bandwidth | |||
Min/Max LSP Bandwidth should cover both two ways. | should cover both two ways. | |||
Network element | Network element | |||
............................. | ............................. | |||
: -------- : | : -------- : | |||
: | PSC | : | : | PSC | : | |||
Link1 -------------<->--|#a | : | Link1 -------------<->--|#a | : | |||
: +--<->---|#b | : | : +--<->---|#b | : | |||
: | -------- : | : | -------- : | |||
TDM : | ---------- : | TDM : | ---------- : | |||
+PSC : +--<->--|#c TDM | : | +PSC : +--<->--|#c TDM | : | |||
Link2 ------------<->--|#d | : | Link2 ------------<->--|#d | : | |||
: ---------- : | : ---------- : | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
:............................ | :............................ | |||
Figure 5a. Hybrid node. | Figure 5a. 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 are | In GMPLS-based multi-region/multi-layer networks, TE Links are | |||
consolidated into a single Traffic Engineering Database (TED). | consolidated into a single Traffic Engineering Database (TED) for | |||
Since this TED contains the information relative to all the layers | use by the single control plane instance. Since this TED contains | |||
of all regions in the network, a path across multiple layers | the information relative to all the layers of all regions in the | |||
(possibly crossing multiple regions) can be computed using the | network, a path across multiple layers (possibly crossing multiple | |||
information in this TED. Thus optimization of network resources | regions) can be computed using the information in this TED. Thus | |||
across the multiple layers of the same region and multiple regions | optimization of network resources across the multiple layers of the | |||
can be achieved. | same region and across multiple regions can be achieved. | |||
These concepts allow for the operation of one network layer over | These concepts allow for the operation of one network layer over | |||
the topology (that is, TE links) provided by other network layer(s) | the topology (that is, TE links) provided by other network layers | |||
(for example, the use of a lower layer LSC LSP carrying PSC LSPs). | (for example, the use of a lower layer LSC LSP carrying PSC LSPs). | |||
In turn, a greater degree of control and inter-working can be | In turn, a greater degree of control and inter-working can be | |||
achieved, including (but not limited too): | achieved, including (but not limited too): | |||
- dynamic establishment of Forwarding Adjacency LSPs (see Section | - dynamic establishment of Forwarding Adjacency LSPs (see Section | |||
4.3.3) | 4.3.3) | |||
- 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 | Note that in a multi-layer/multi-region network that includes | |||
multi-switching type capable nodes, an explicit route used to | multi-switching-type-capable nodes, an explicit route used to | |||
establish an end-to-end LSP can specify nodes that belong to | establish an end-to-end LSP can specify nodes that belong to | |||
different layers or regions. In this case, a mechanism to control | different layers or regions. In this case, a mechanism to control | |||
the dynamic creation of FA LSPs may be required. | the dynamic creation of FA LSPs may be required. | |||
There is a full spectrum of options to control how FA LSPs are | There is a full spectrum of options to control how FA LSPs are | |||
dynamically established. It can be subject to the control of a | dynamically established. The process can be subject to the control | |||
policy, which may be set by a management component, and which may | of a policy, which may be set by a management component, and which | |||
require that the management plane is consulted at the time that the | may require that the management plane is consulted at the time that | |||
FA LSP is established. Alternatively, the FA LSP can be established | the FA LSP is established. Alternatively, the FA LSP can be | |||
at the request of the control plane without any management control. | established at the request of the control plane without any | |||
management control. | ||||
4.3.1. Triggered signaling | 4.3.1. Triggered signaling | |||
When an LSP crosses the boundary from an upper to a lower layer, it | When an LSP crosses the boundary from an upper to a lower layer, it | |||
may be nested into a lower layer FA LSP that crosses the lower | may be nested into a lower layer FA LSP that crosses the lower | |||
layer. From signaling perspective, there are two alternatives to | layer. From a signaling perspective, there are two alternatives to | |||
establish lower layer FA LSP: static and dynamic. Decision will be | establish the lower layer FA LSP: static (pre-provisioned) and | |||
made either by the operator or automatically using features like | dynamic (triggered). Pre-provisioned FA-LSP will be initiated | |||
TE auto-mesh, for instance. If such a lower layer LSP does not | either by the operator or automatically using features like TE | |||
already exist, the LSP may be established dynamically. Such a | auto-mesh [AUTO-MESH]. If such a lower layer LSP does not already | |||
mechanism is referred to as "triggered signaling". | exist, the LSP may be established dynamically. Such a mechanism is | |||
referred to as "triggered signaling". | ||||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
4.3.2. FA-LSP | 4.3.2. FA-LSP | |||
Once an LSP is created across a layer, it can be used as a data | Once an LSP is created across a layer, it can be used as a data | |||
link in an upper layer. | link in an upper layer. | |||
Furthermore, it can be advertised as a TE-link, allowing other | Furthermore, it can be advertised as a TE-link, allowing other | |||
nodes to consider the LSP as a TE link for their path computation | nodes to consider the LSP as a TE link for their path computation | |||
[HIER]. An LSP created either statically or dynamically by one | [RFC4206]. An LSP created either statically or dynamically by one | |||
instance of the control plane and advertised as a TE link into the | instance of the control plane and advertised as a TE link into the | |||
same instance of the control plane is called a FA-LSP. The TE-link | same instance of the control plane is called a Forwarding adjacency | |||
associated to an FA-LSP is called an FA. An FA has the special | LSP (FA-LSP). The TE-link as which the FA-LSP is advertised is | |||
characteristic of not requiring a routing adjacency (peering) | called an FA. An FA has the special characteristic of not requiring | |||
between its ends yet still guaranteeing control plane connectivity | a routing adjacency (peering) between its end points yet still | |||
between the FA-LSP ends based on a signaling adjacency. A FA is a | guaranteeing control plane connectivity between the FA-LSP end | |||
useful and powerful tool for improving the scalability of GMPLS | points based on a signaling adjacency. A FA is a useful and | |||
Traffic Engineering (TE) capable networks. | 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) | The aggregation of LSPs enables the creation of a vertical (nested) | |||
LSP Hierarchy. A set of FA-LSPs across or within a lower layer can | LSP Hierarchy. A set of FA-LSPs across or within a lower layer can | |||
be used during path selection by a higher layer LSP. Likewise, the | be used during path selection by a higher layer LSP. Likewise, the | |||
higher layer LSPs may be carried over dynamic data links realized | higher layer LSPs may be carried over dynamic data links realized | |||
via LSPs (just as they are carried over any "regular" static data | via LSPs (just as they are carried over any "regular" static data | |||
links). This process requires the nesting of LSPs through a | links). This process requires the nesting of LSPs through a | |||
hierarchical process [HIER]. The TED contains a set of LSP | hierarchical process [RFC4206]. The TED contains a set of LSP | |||
advertisements from different layers that are identified by the | advertisements from different layers that are identified by the | |||
ISCD contained within the TE link advertisement associated with the | ISCD contained within the TE link advertisement associated with the | |||
LSP [GMPLS-ROUTING]. | LSP [RFC4202]. | |||
If a lower layer LSP is not advertised as an FA, it can still be | ||||
used 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. | ||||
4.3.3. Virtual network topology (VNT) | 4.3.3. Virtual network topology (VNT) | |||
A set of one or more of lower-layer LSPs provides information for | A set of one or more of lower-layer LSPs provides information for | |||
efficient path handling in upper-layer(s) of the MLN, or, in other | efficient path handling in upper-layer(s) of the MLN, or, in other | |||
words, provides a virtual network topology to the upper-layers. For | words, provides a virtual network topology (VNT) to the upper- | |||
instance, a set of LSPs, each of which is supported by an LSC LSP, | layers. For instance, a set of LSPs, each of which is supported by | |||
provides a virtual network topology to the layers of a PSC region, | an LSC LSP, provides a virtual network topology to the layers of a | |||
assuming that the PSC region is connected to the LSC region. Note | PSC region, assuming that the PSC region is connected to the LSC | |||
that a single lower-layer LSP is a special case of VNT. The virtual | region. Note that a single lower-layer LSP is a special case of the | |||
network topology is configured by setting up or tearing down the | VNT. The virtual network topology is configured by setting up or | |||
LSC LSPs. By using GMPLS signaling and routing protocols, the | tearing down the lower layer LSPs. By using GMPLS signaling and | |||
virtual network topology can be adapted to traffic demands. | routing protocols, the virtual network topology can be adapted to | |||
traffic demands. | ||||
Reconfiguration of the virtual network topology may be triggered by | Reconfiguration of the virtual network topology may be triggered by | |||
traffic demand change, topology configuration change, signaling | traffic demand changes, topology configuration changes, signaling | |||
request from the upper layer, and network failure. For instance, by | requests from the upper layer, and network failures. For instance, | |||
reconfiguring the virtual network topology according to the traffic | by reconfiguring the virtual network topology according to the | |||
demand between source and destination node pairs, network | traffic demand between source and destination node pairs, network | |||
performance factors, such as maximum link utilization and residual | performance factors, such as maximum link utilization and residual | |||
capacity of the network, can be optimized [MAMLTE]. Reconfiguration | capacity of the network, can be optimized [MAMLTE]. Reconfiguration | |||
is performed by computing the new VNT from the traffic demand | is performed by computing the new VNT from the traffic demand | |||
matrix and optionally from the current VNT. Exact details are | matrix and optionally from the current VNT. Exact details are | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
outside the scope of this document. However, this method may be | outside the scope of this document. However, this method may be | |||
tailored according to the Service Provider's policy regarding | tailored according to the service provider's policy regarding | |||
network performance and quality of service (delay, loss/disruption, | network performance and quality of service (delay, loss/disruption, | |||
utilization, residual capacity, reliability). | utilization, residual capacity, reliability). | |||
5. Service networks provided over MRN/MLN | 5.Requirements | |||
A customer network may be provided on top of a server MRN/MLN | ||||
network (such as a transport network) which is operated by a | ||||
service provider. For example legacy IP or IP/MPLS networks can be | ||||
provided on top of GMPLS packet or optical networks [IW-MIG-FW]. | ||||
The relationship between the networks is a client/server | ||||
relationship and, such services are referred to as "MRN/MLN | ||||
services". | ||||
The customer network may be provided either as part of the MRN/MLN | ||||
or in a separate network instance distinct from the MRN/MLN. There | ||||
could also be an administrative boundary between the customer | ||||
network and the MRN/MLN operated by the service provider. All | ||||
requirements described in this document SHOULD be applicable if | ||||
there is an administrative boundary between the customer network | ||||
and the MRN/MLN operated by service provider. | ||||
Impact on the customer network design, operation, and | ||||
administration SHOULD be minimized. For instance, the design for | ||||
address assignment and IGP area division should be kept independent | ||||
from the underlying MRN/MLN. | ||||
The MRN/MLN SHOULD provide mechanisms to allow an administrative | ||||
boundary between the customer network and the MRN/MLN. | ||||
6. Requirements | ||||
6.1. Scalability | 5.1. Scalability | |||
The MRN/MLN relies on a unified traffic engineering and routing | The MRN/MLN relies on a unified traffic engineering and routing | |||
model. The TED in each LSR is populated with TE-links from all | model. The TED in each LSR is populated with TE-links from all | |||
layers of all regions. This may lead to a huge amount of | layers of all regions. This may lead to a huge amount of | |||
information that has to be flooded and stored within the network. | information that has to be flooded and stored within the network. | |||
Furthermore, path computation times, which may be of great | Furthermore, path computation times, which may be of great | |||
importance during restoration, will depend on the size of the TED. | importance during restoration, will depend on the size of the TED. | |||
Thus MRN/MLN routing mechanisms MUST be designed to scale well with | Thus MRN/MLN routing mechanisms MUST be designed to scale well with | |||
an increase of any of the following: | an increase of any of the following: | |||
skipping to change at page 11, line 50 | skipping to change at page 12, line 4 | |||
The MRN/MLN relies on a unified traffic engineering and routing | The MRN/MLN relies on a unified traffic engineering and routing | |||
model. The TED in each LSR is populated with TE-links from all | model. The TED in each LSR is populated with TE-links from all | |||
layers of all regions. This may lead to a huge amount of | layers of all regions. This may lead to a huge amount of | |||
information that has to be flooded and stored within the network. | information that has to be flooded and stored within the network. | |||
Furthermore, path computation times, which may be of great | Furthermore, path computation times, which may be of great | |||
importance during restoration, will depend on the size of the TED. | importance during restoration, will depend on the size of the TED. | |||
Thus MRN/MLN routing mechanisms MUST be designed to scale well with | Thus MRN/MLN routing mechanisms MUST be designed to scale well with | |||
an increase of any of the following: | an increase of any of the following: | |||
- Number of nodes | - Number of nodes | |||
- Number of TE-links (including FA-LSPs) | - Number of TE-links (including FA-LSPs) | |||
- Number of LSPs | - Number of LSPs | |||
- Number of regions and layers | - Number of regions and layers | |||
- Number of ISCDs per TE-link. | - Number of ISCDs per TE-link. | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | Further, design of the routing protocols MUST NOT prevent TE | |||
information filtering based on ISCDs. Signaling protocol SHOULD be | ||||
able to operate on partial TE information. | ||||
6.2. LSP resource utilization | 5.2. LSP resource utilization | |||
It MUST be possible to utilize network resources efficiently. | It MUST be possible to utilize network resources efficiently. | |||
Particularly, resource usage in all layers SHOULD be optimized as a | Particularly, resource usage in all layers SHOULD be optimized as a | |||
whole (i.e. across all layers), in a coordinated manner, (ie taking | whole (i.e., across all layers), in a coordinated manner, (i.e., | |||
all layers into account). The number of lower-layer LSPs carrying | taking all layers into account). The number of lower-layer LSPs | |||
upper-layer LSPs SHOULD be minimized as much as possible (Note that | carrying upper-layer LSPs SHOULD be minimized (Note that multiple | |||
multiple LSPs may be used for load balance) . Unneccesary lower- | LSPs MAY be used for load balancing). Unneccesary lower-layer LSPs, | |||
layer LSPs SHOULD be avoided. | which would not carry any traffic by rerouting the traffic over it | |||
to alternative lower-layer LSPs, SHOULD be avoided. | ||||
6.2.1. FA-LSP release and setup | 5.2.1. FA-LSP release and setup | |||
Statistical multiplexing can only be employed in PSC and L2SC | Statistical multiplexing can only be employed in PSC and L2SC | |||
regions. A PSC or L2SC LSP may or may not consume the maximum | regions. A PSC or L2SC LSP may or may not consume the maximum | |||
reservable bandwidth of the FA LSP that carries it. On the other | reservable bandwidth of the FA LSP that carries it. On the other | |||
hand, a TDM, or LSC LSP always consumes a fixed amount of bandwidth | hand, a TDM, or LSC LSP always consumes a fixed amount of bandwidth | |||
as long as it exists (and is fully instantiated) because | as long as it exists (and is fully instantiated) because | |||
statistical multiplexing is not available. | statistical multiplexing is not available. | |||
If there is low traffic demand, some FA LSPs, which do not carry | If there is low traffic demand, some FA LSPs that do not carry any | |||
any LSP may be released so that resources are released. Note that | LSP MAY be released so that lower-layer resources are released. | |||
if a small fraction of the available bandwidth is still under use, | Note that if a small fraction of the available bandwidth of an FA- | |||
the nested LSPs can also be re-routed optionally using the make- | LSP is still in use, the nested LSPs can also be re-routed to other | |||
before-break technique. Alternatively, the FA LSPs may be retained | FA-LSPs (optionally using the make-before-break technique) to | |||
for future usage. Release or retention of underutilized FA LSPs is | complete free up the FA-LSP. Alternatively, the FA LSPs MAY be | |||
a policy decision. | 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 | As part of the re-optimization process, the solution MUST allow | |||
rerouting of FA LSPs while keeping interface identifiers of | rerouting of an FA LSP while keeping interface identifiers of | |||
corresponding TE links unchanged. | corresponding TE links unchanged. Further, this process MUST be | |||
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 | Additional FA LSPs MAY also be created based on policy, which might | |||
consider residual resources and the change of traffic demand across | consider residual resources and the change of traffic demand across | |||
the region. By creating the new FA LSPs, the network performance | the region. By creating the new FA LSPs, the network performance | |||
such as maximum residual capacity may increase. | such as maximum residual capacity may increase. | |||
As the number of FA LSPs grows, the residual resource may decrease. | As the number of FA LSPs grows, the residual resource may decrease. | |||
In this case, re-optimization of FA LSPs MAY be invoked according | In this case, re-optimization of FA LSPs MAY be invoked according | |||
the policy. | to policy. | |||
Any solution MUST include measures to protect against network | Any solution MUST include measures to protect against network | |||
destabilization caused by the rapid set up and tear down of LSPs as | destabilization caused by the rapid set up and tear down of LSPs as | |||
traffic demand varies near a threshold. | traffic demand varies near a threshold. | |||
6.2.2. Virtual TE-Link | 5.2.2. Virtual TE-Link | |||
It may be considered disadvantageous to fully instantiate (i.e. | It may be considered disadvantageous to fully instantiate (i.e. | |||
pre-provision) the set of lower layer LSPs since this may reserve | pre-provision) the set of lower layer LSPs that provide the VNT | |||
bandwidth that could be used for other LSPs in the absence of the | since this might reserve bandwidth that could be used for other | |||
upper-layer traffic. | LSPs in the absence of the upper-layer traffic. | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
However, in order to provision upper-layer LSPs across the lower- | However, in order to allow path computation of upper-layer LSPs | |||
layer, the LSPs MAY still be advertised into the upper-layer as | across the lower-layer, the lower-layer LSPs MAY be advertised into | |||
though they had been fully established. Such TE links that | the upper-layer as though they had been fully established, but | |||
represent the possibility of an underlying LSP are termed "virtual | without actually establishing them. Such TE links that represent | |||
TE-link". Note that this is not a mandatory (MUST) requirement | the possibility of an underlying LSP are termed "virtual TE-link". | |||
since even if there are no LSPs advertised to the higher layer, it | It is an implementation choice at a boundary node whether to create | |||
is possible to route an upper layer LSP into a lower layer based on | virtual TE-links, and the choice if available MUST be under the | |||
the lower layer's TE-links and making assumptions that proper | control of operator policy. Note that there is no requirement to | |||
hierarchical LSPs in the lower layer will be dynamically created as | support the creation of virtual TE-links, since real TE-links (with | |||
needed. | 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, | If an upper-layer LSP that makes use of a virtual TE-Link is set up, | |||
the underlying LSP MUST be immediately signaled in the lower layer | the underlying LSP MUST be immediately signaled in the lower layer. | |||
if it has not been established. | ||||
If virtual TE-Links are used in place of pre-established LSPs, the | If virtual TE-Links are used in place of pre-established LSPs, the | |||
TE links across the upper-layer can remain stable using pre- | TE-links across the upper-layer can remain stable using pre- | |||
computed paths while wastage of bandwidth within the lower-layer | computed paths while wastage of bandwidth within the lower-layer | |||
and unnecessary reservation of adaptation ports at the border nodes | and unnecessary reservation of adaptation ports at the border nodes | |||
can be avoided. | can be avoided. | |||
The concept of VNT can be extended to allow the virtual TE-links to | The concept of the VNT can be extended to allow the virtual TE- | |||
form part of the VNT. The combination of the fully provisioned TE- | links to form part of the VNT. The combination of the fully | |||
links and the virtual TE-links defines the VNT across the lower | provisioned TE-links and the virtual TE-links defines the VNT | |||
layer. | provided by the lower layer. | |||
The solution SHOULD provide operations to facilitate the build-up | The solution SHOULD provide operations to facilitate the build-up | |||
of such virtual TE-links, taking into account the (forecast) | of such virtual TE-links, taking into account the (forecast) | |||
traffic demand and available resource in the lower-layer. | traffic demand and available resource in the lower-layer. | |||
Virtual TE-links MAY be modified dynamically (by adding or removing | Virtual TE-links MAY be modified dynamically (by adding or removing | |||
virtual TE links) according to the change of the (forecast) traffic | virtual TE links, or chancing their capacity) according to the | |||
demand and the available resource in the lower-layer. | change of the (forecast) traffic demand and the available resource | |||
in the lower-layer. | ||||
Any solution MUST include measures to protect against network | Any solution MUST include measures to protect against network | |||
destabilization caused by the rapid changes in the virtual network | destabilization caused by the rapid changes in the virtual network | |||
topology as traffic demand varies near a threshold. | topology as traffic demand varies near a threshold. | |||
The VNT can be changed by setting up and/or tearing down virtual TE | The VNT can be changed by setting up and/or tearing down virtual TE | |||
links as well as by modifying real links (i.e. the fully | links as well as by modifying real links (i.e. the fully | |||
provisioned LSPs). | provisioned LSPs). | |||
The maximum number of virtual TE links that can be configured | The maximum number of virtual TE links that can be defined SHOULD | |||
SHOULD be well-engineered. | be configurable. | |||
How to design the VNT and how to manage it are out of scope of this | How to design the VNT and how to manage it are out of scope of this | |||
document and will be treated in a companion document on solution. | document. | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
6.3. LSP Attribute inheritance | 5.3. LSP Attribute inheritance | |||
TE-Link parameters SHOULD be inherited from the parameters of the | TE-Link parameters SHOULD be inherited from the parameters of the | |||
LSP that provides the TE link, and so from the TE links in the | LSP that provides the TE-link, and so from the TE-links in the | |||
lower layer that are traversed by the LSP. | lower layer that are traversed by the LSP. | |||
These include: | These include: | |||
- 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) | |||
Inheritance rules MUST be applied based on specific policies. | Inheritance rules MUST be applied based on specific policies. | |||
Particular attention should be given to the inheritance of TE | Particular attention should be given to the inheritance of TE | |||
metric (which may be other than a strict sum of the metrics of the | metric (which may be other than a strict sum of the metrics of the | |||
component TE links at the lower layer) and protection attributes. | component TE links at the lower layer) and protection attributes. | |||
6.4. Verification of the LSP | 5.4. Verification of the LSP | |||
When the LSP is created, it SHOULD be verified that it has been | ||||
established before it can be used by an upper layer LSP. Note, this | ||||
is not within the GMPLS capability scope for non-PSC interfaces. | ||||
6.5. Disruption minimization | When a lower layer LSP is established for use as a data link by a | |||
higher layer, the LSP MAY be verified for correct connectivity and | ||||
data integrity. Such mechanisms are data technology-specific and | ||||
are beyond the scope of this document, but may be coordinated | ||||
through the GMPLS control plane. | ||||
5.5. Disruption minimization | ||||
When reconfiguring the VNT according to a change in traffic demand, | When reconfiguring the VNT according to a change in traffic demand, | |||
the upper-layer LSP might be disrupted. Such disruption MUST be | the upper-layer LSP might be disrupted. Such disruption to the | |||
minimized. | upper layers MUST be minimized. | |||
When residual resource decreases to a certain level, some LSPs MAY | When residual resource decreases to a certain level, some lower | |||
be released according to local or network policies. There is a | layer LSPs MAY be released according to local or network policies. | |||
trade-off between minimizing the amount of resource reserved in the | There is a trade-off between minimizing the amount of resource | |||
lower layer LSPs and disrupting higher layer traffic (i.e. moving | reserved in the lower layer and disrupting higher layer traffic | |||
the traffic to other TE-LSPs so that some LSPs can be released). | (i.e. moving the traffic to other TE-LSPs so that some LSPs can be | |||
Such traffic disruption MAY be allowed but MUST be under the | released). Such traffic disruption MAY be allowed but MUST be under | |||
control of policy that can be configured by the operator. Any | the control of policy that can be configured by the operator. Any | |||
repositioning of traffic MUST be as non-disruptive as possible (for | repositioning of traffic MUST be as non-disruptive as possible (for | |||
example, using make-before-break). | example, using make-before-break). | |||
6.6. Stability | 5.6. Stability | |||
The path computation is dependent on the network topology and | Path computation is dependent on the network topology and | |||
associated link state. The path computation stability of an upper | associated link state. The path computation stability of an upper | |||
layer may be impaired if the VNT changes frequently and/or if the | layer may be impaired if the VNT changes frequently and/or if the | |||
status and TE parameters (TE metric for instance) of links in the | status and TE parameters (TE metric for instance) of links in the | |||
virtual network topology changes frequently. | virtual network topology changes frequently. | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
In this context, robustness of the VNT is defined as the capability | In this context, robustness of the VNT is defined as the capability | |||
to smooth changes that may occur and avoid their propagation into | to smooth changes that may occur and avoid their propagation into | |||
higher layers. Changes of the VNT may be caused by the creation | higher layers. Changes of the VNT may be caused by the creation, | |||
and/or deletion of several LSPs. | deletion, or modification of several LSPs. | |||
Creation and deletion of LSPs MAY be triggered by adjacent layers | Creation, deletion and modification of LSPs MAY be triggered by | |||
or through operational actions to meet traffic demand change, | adjacent layers or through operational actions to meet traffic | |||
topology change, signaling request from the upper layer, and | demand changes, topology changes, signaling requests from the upper | |||
network failure. Routing robustness SHOULD be traded with | layer, and network failures. Routing robustness SHOULD be traded | |||
adaptability with respect to the change of incoming traffic | with adaptability with respect to the change of incoming traffic | |||
requests. | requests. | |||
A full mesh of LSPs MAY be created between every pair of border | A full mesh of LSPs MAY be created between every pair of border | |||
nodes of the PSC region. The merit of a full mesh of PSC TE-LSPs is | nodes of the higher layer. The merit of a full mesh of PSC TE-LSPs | |||
that it provides stability to the PSC-level routing. That is, the | is that it provides stability to the higher layer routing. That is, | |||
forwarding table of an PSC-LSR is not impacted by re-routing | the TED or forwarding table used in the higher layer of an PSC-LSR | |||
changes within the lower-layer (e.g., TDM layer). Further, there is | is not impacted by routing changes within the lower-layer (e.g., | |||
always full PSC reachability and immediate access to bandwidth to | TDM layer). Further, there is always full PSC reachability and | |||
support PSC LSPs. But it also has significant drawbacks, since it | immediate access to bandwidth to support LSPs in the higher layer. | |||
requires the maintenance of n^2 RSVP-TE sessions, which may be | But it also has significant drawbacks, since it requires the | |||
quite CPU and memory consuming (scalability impact). Also this may | maintenance of n^2 RSVP-TE sessions, which may be quite CPU and | |||
lead to significant bandwidth wasting if LSP with a certain amount | memory consuming (scalability impact). Also this may lead to | |||
of reserved bandwidth is used. | significant bandwidth wastage if LSPs with a certain amount of | |||
Note that the use of virtual TE-links solves the bandwidth wasting | reserved bandwidth are used. | |||
Note that the use of virtual TE-links solves the bandwidth wastage | ||||
issue, and may reduce the control plane overload. | issue, and may reduce the control plane overload. | |||
6.7. Computing paths with and without nested signaling | 5.7. Computing paths with and without nested signaling | |||
Path computation MAY take into account LSP region and layer | Path computation MAY take into account LSP region and layer | |||
boundaries when computing a path for an LSP. For example, path | boundaries when computing a path for an LSP. For example, path | |||
computation MAY restrict the path taken by an LSP to only the links | computation MAY restrict the path taken by an LSP to only the links | |||
whose interface switching capability is PSC. | whose interface switching capability is PSC. | |||
Interface switching capability is used as a constraint in computing | Interface switching capability is used as a constraint in path | |||
the path. A TDM-LSP is routed over the topology composed of TE | computation. For example, a TDM-LSP is routed over the topology | |||
links of the same TDM layer. In calculating the path for the LSP, | composed of TE links of the same TDM layer. In calculating the path | |||
the TE database MAY be filtered to include only links where both | for the LSP, the TED MAY be filtered to include only links where | |||
end include requested LSP switching type. In this way hierarchical | both end include requested LSP switching type. In this way | |||
routing is done by using a TE database filtered with respect to | hierarchical routing is done by using a TED filtered with respect | |||
switching capability (that is, with respect to particular layer). | to switching capability (that is, with respect to particular layer). | |||
If triggered signaling is allowed, the path computation mechanism | If triggered signaling is allowed, the path computation mechanism | |||
MAY produce a route containing multiple layers/ regions. The path | MAY produce a route containing multiple layers/regions. The path is | |||
is computed over the multiple layers/regions even if the path is | computed over the multiple layers/regions even if the path is not | |||
not "connected" in the same layer as the endpoints of the path | "connected" in the same layer as the endpoints of the path exist. | |||
exist. Note that here we assume that triggered signaling will be | Note that here we assume that triggered signaling will be invoked | |||
invoked to make the path "connected", when the upper-layer | to make the path "connected", when the upper-layer signaling | |||
signaling request arrives at the boundary node. | request arrives at the boundary node. | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | The upper-layer signaling request may contain an ERO that includes | |||
only hops in the upper layer, in which case the boundary node is | ||||
responsible for triggered creating of the lower-layer FA-LSP using | ||||
a path of its choice, or for the selection of any available lower | ||||
layer LSP as a data link for the higher layer. This mechanism is | ||||
appropriate for environments where the TED is filtered in the | ||||
higher layer, where separate routing instances are used per layer, | ||||
or where administrative policies prevent the higher layer from | ||||
specifying paths through the lower layer. | ||||
The upper-layer signaling request may contain a loose ERO, and the | Obviously, if the lower layer LSP has been advertised as a TE link | |||
boundary node is responsible for creation of the lower-layer FA-LSP. | (virtual or real) into the higher layer, then the higher layer | |||
When the boundary node receives the signaling setup request and | signaling request may contain the TE link identifier and so | |||
determines that it has to expand the loose ERO content by creating | indicate the lower layer resources to be used. But in this case, | |||
the lower-layer FA-LSP, it will create the lower layer FA-LSP | the path of the lower layer LSP can be dynamically changed by the | |||
accordingly. Once the lower-layer LSP is established, the ERO | lower layer at any time. | |||
contents for the upper-layer signaling setup request are expanded | ||||
to include the lower-layer FA-LSP and signaling setup for the | ||||
upper-layer LSP are carried in-band of the lower-layer LSP. | ||||
The upper-layer signaling request may contain a strict ERO | Alternatively, the upper-layer signaling request may contain an ERO | |||
specifying the lower layer FA-LSP route. In this case, the boundary | specifying the lower layer FA-LSP route. In this case, the boundary | |||
node is responsible for decision as to which it should use the path | node is responsible for decision as to which it should use the path | |||
contained in the strict ERO or it should re-compute the path within | contained in the strict ERO or it should re-compute the path within | |||
in the lower-layer. | in the lower-layer. | |||
Even in case the lower-layer FA-LSPs are already established, a | Even in case the lower-layer FA-LSPs are already established, a | |||
signaling request may also be encoded as loose ERO. In this | signaling request may also be encoded as loose ERO. In this | |||
situation, it is up to the boundary node to decide whether it | situation, it is up to the boundary node to decide whether it | |||
should a new lower-layer FA-LSP or it should use the existing | should a new lower-layer FA-LSP or it should use the existing | |||
lower-layer FA-LSPs. | lower-layer FA-LSPs. | |||
We should note that the lower-layer FA-LSP can be advertised just | The lower-layer FA-LSP can be advertised just as an FA-LSP in the | |||
as an FA-LSP in the upper-layer or an IGP adjacency can be brought | upper-layer or an IGP adjacency can be brought up on the lower- | |||
up on the lower-layer FA-LSP. | layer FA-LSP. | |||
6.8. Handling single-switching and multi-switching type capable | 5.8. Handling single-switching and multi-switching-type-capable | |||
nodes | nodes | |||
The MRN/MLN can consist of single-switching type capable and multi- | The MRN/MLN can consist of single-switching-type-capable and multi- | |||
switching type capable nodes. The path computation mechanism in the | switching-type-capable nodes. The path computation mechanism in the | |||
MLN SHOULD be able to compute paths consisting of any combination | MLN SHOULD be able to compute paths consisting of any combination | |||
of such nodes. | of such nodes. | |||
Both single switching capable and multi-switching (simplex or | Both single-switching-type-capable and multi-switching-type-capable | |||
hybrid) capable nodes could play the role of layer boundary. | (simplex or hybrid) nodes could play the role of layer boundary. | |||
MRN/MLN Path computation SHOULD handle TE topologies built of any | MRN/MLN Path computation SHOULD handle TE topologies built of any | |||
combination of single switching, simplex and hybrid nodes | combination of nodes | |||
6.9. Advertisement of the available adaptation resource | 5.9. Advertisement of the available adaptation resource | |||
A hybrid node SHOULD maintain resources and advertise the resource | A hybrid node SHOULD maintain resources and advertise the resource | |||
information on its internal links, the links required for vertical | information on its internal links, the links required for vertical | |||
(layer) integration. Likewise, path computation elements SHOULD be | (layer) integration. Likewise, path computation elements SHOULD be | |||
prepared to use the availability of termination/adaptation | prepared to use the availability of termination/adaptation | |||
resources as a constraint in MRN/MLN path computations to reduce | resources as a constraint in MRN/MLN path computations to reduce | |||
the higher layer LSP setup blocking probability because of the lack | the higher layer LSP setup blocking probability because of the lack | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
of necessary termination/ adaptation resources in the lower | of necessary termination/ adaptation resources in the lower | |||
layer(s). | layer(s). | |||
The advertisement of the adaptation capability to terminate LSPs of | The advertisement of the adaptation capability to terminate LSPs of | |||
lower-region and forward traffic in the upper-region is REQUIRED, | lower-region and forward traffic in the upper-region is REQUIRED, | |||
as it provides critical information when performing multi-region | as it provides critical information when performing multi-region | |||
path computation. | path computation. | |||
The mechanism SHOULD cover the case where the upper-layer links | The mechanism SHOULD cover the case where the upper-layer links | |||
which are directly connected to upper-layer switching element and | which are directly connected to upper-layer switching element and | |||
the ones which are connected through internal links between upper- | the ones which are connected through internal links between upper- | |||
layer element and lower-layer element coexist (See section 4.2.1). | layer element and lower-layer element coexist (See section 4.2.1). | |||
7. Security Considerations | 6. Security Considerations | |||
The current version of this document does not introduce any new | The current version of this document does not introduce any new | |||
security considerations as it only lists a set of requirements. In | security considerations as it only lists a set of requirements. In | |||
the future versions, new security requirements may be added. | the future versions, new security requirements may be added. | |||
8. References | 7. References | |||
8.1. Normative Reference | 7.1. Normative Reference | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to | ||||
Indicate Requirement Levels", BCP 14, RFC 2119, | ||||
March 1997. | ||||
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF | [RFC3979] Bradner, S., "Intellectual Property Rights in IETF | |||
Technology", BCP 79, RFC 3979, March 2005. | Technology", BCP 79, RFC 3979, March 2005. | |||
[GMPLS-ROUTING] K.Kompella and Y.Rekhter, "Routing Extensions in | [RFC4202] K.Kompella and Y.Rekhter, "Routing Extensions in | |||
Support of Generalized Multi-Protocol Label | Support of Generalized Multi-Protocol Label | |||
Switching," draft-ietf-ccamp-gmpls-routing-09.txt, | Switching (GMPLS)," RFC4202, October 2005. | |||
October 2003 (work in progress). | ||||
[Inter-domain] A.Farrel, J-P. Vasseur, and A.Ayyangar, "A | [Inter-domain] A.Farrel, J-P. Vasseur, and A.Ayyangar, "A | |||
framework for inter-domain MPLS traffic | framework for inter-domain MPLS traffic | |||
engineering," draft-ietf-ccamp-inter-domain- | engineering," draft-ietf-ccamp-inter-domain- | |||
framework, work in progress. | framework, work in progress. | |||
[HIER] K.Kompella and Y.Rekhter, "LSP hierarchy with | [RFC4206] K.Kompella and Y.Rekhter, "Label Switched Paths (LSP) | |||
generalized MPLS TE," draft-ietf-mpls-lsp-hierarchy- | Hierarchy with Generalized Multi-Protocol Label | |||
08.txt, work in progress, Sept. 2002. | Switching (GMPLS) Traffic Engineering (TE)," | |||
RFC4206, Oct. 2005. | ||||
[STITCH] Ayyangar, A. and Vasseur, JP., "Label Switched Path | [STITCH] Ayyangar, A. and Vasseur, JP., "Label Switched Path | |||
Stitching with Generalized MPLS Traffic Engineering", | Stitching with Generalized MPLS Traffic Engineering", | |||
draft-ietf-ccamp-lsp-stitching, work in progress. | draft-ietf-ccamp-lsp-stitching, work in progress. | |||
[LMP] J. Lang, "Link management protocol (LMP)," draft- ietf- | [RFC4204] J. Lang, "Link management protocol (LMP)," RFC4204, | |||
ccamp-lmp-10.txt (work in progress), October 2003. | October 2005. | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
[RFC3945] E.Mannie (Ed.), "Generalized Multi-Protocol Label | [RFC3945] E.Mannie (Ed.), "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Architecture", RFC 3945, October | Switching (GMPLS) Architecture", RFC 3945, October | |||
2004. | 2004. | |||
8.2. Informative References | 7.2. Informative References | |||
[MAMLTE] K. Shiomoto et al., "Multi-area multi-layer traffic | [MAMLTE] K. Shiomoto et al., "Multi-area multi-layer traffic | |||
engineering using hierarchical LSPs in GMPLS | engineering using hierarchical LSPs in GMPLS | |||
networks", draft-shiomoto-multiarea-te, work in | networks", draft-shiomoto-multiarea-te, work in | |||
progress. | progress. | |||
[MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., | [MRN-EVAL] Le Roux, J.L., Brungard, D., Oki, E., Papadimitriou, D., | |||
Shiomoto, K., Vigoureux, M.,"Evaluation of existing | Shiomoto, K., Vigoureux, M.,"Evaluation of existing | |||
GMPLS Protocols against Multi Layer and Multi Region | GMPLS Protocols against Multi Layer and Multi Region | |||
Networks (MLN/MRN)", draft-leroux-ccamp-gmpls-mrn- | Networks (MLN/MRN)", draft-leroux-ccamp-gmpls-mrn- | |||
eval, work in progress. | eval, work in progress. | |||
[IW-MIG-FW] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., | [IW-MIG-FW] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., | |||
Brungard, D., Oki, E., Inoue, I., " Framework for | Brungard, D., Oki, E., Inoue, I., " Framework for | |||
IP/MPLS-GMPLS interworking in support of IP/MPLS to | IP/MPLS-GMPLS interworking in support of IP/MPLS to | |||
GMPLS migration ", draft-shiomoto-ccamp-mpls-gmpls- | GMPLS migration ", draft-ietf-ccamp-mpls-gmpls- | |||
interwork-fmwk-00.txt, work in progress. | interwork-fmwk-00.txt, work in progress. | |||
9. Author's Addresses | [AUTO-MESH] Vasseur, JP., Le Roux, JL., et al., "Routing | |||
extensions for discovery of Multiprotocol (MPLS) | ||||
Label Switch Router (LSR) Traffic Engineering (TE) | ||||
mesh membership", draft-ietf-ccamp-automesh, work in | ||||
progress. | ||||
8. Author's 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 | Alcatel | |||
Francis Wellensplein 1, | Francis Wellensplein 1, | |||
B-2018 Antwerpen, Belgium | B-2018 Antwerpen, Belgium | |||
Phone : +32 3 240 8491 | Phone : +32 3 240 8491 | |||
Email: dimitri.papadimitriou@alcatel.be | Email: dimitri.papadimitriou@alcatel.be | |||
Jean-Louis Le Roux | Jean-Louis Le Roux | |||
France Telecom R&D, | France Telecom R&D, | |||
Av Pierre Marzin, | Av Pierre Marzin, | |||
22300 Lannion, France | 22300 Lannion, France | |||
Email: jeanlouis.leroux@francetelecom.com | Email: jeanlouis.leroux@orange-ft.com | |||
Martin Vigoureux | Martin Vigoureux | |||
Alcatel | Alcatel | |||
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 | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
Email: martin.vigoureux@alcatel.fr | Email: martin.vigoureux@alcatel.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 | |||
Contributors | Contributors | |||
skipping to change at page 19, line 29 | skipping to change at page 20, line 16 | |||
Phone: +81 422 59 3441 Email: oki.eiji@lab.ntt.co.jp | Phone: +81 422 59 3441 Email: oki.eiji@lab.ntt.co.jp | |||
Ichiro Inoue (NTT Network Service Systems Laboratories) | Ichiro Inoue (NTT Network Service Systems Laboratories) | |||
3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan | 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan | |||
Phone: +81 422 59 3441 Email: ichiro.inoue@lab.ntt.co.jp | Phone: +81 422 59 3441 Email: ichiro.inoue@lab.ntt.co.jp | |||
Emmanuel Dotaro (Alcatel) | Emmanuel Dotaro (Alcatel) | |||
Route de Nozay, 91461 Marcoussis cedex, France | Route de Nozay, 91461 Marcoussis cedex, France | |||
Phone : +33 1 6963 4723 Email: emmanuel.dotaro@alcatel.fr | Phone : +33 1 6963 4723 Email: emmanuel.dotaro@alcatel.fr | |||
10. Intellectual Property Considerations | 9. Intellectual Property Considerations | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed | Intellectual Property Rights or other rights that might be claimed | |||
to pertain to the implementation or use of the technology described | to pertain to the implementation or use of the technology described | |||
in this document or the extent to which any license under such | in this document or the extent to which any license under such | |||
rights might or might not be available; nor does it represent that | rights might or might not be available; nor does it represent that | |||
it has made any independent effort to identify any such rights. | it has made any independent effort to identify any such rights. | |||
Information on the procedures with respect to rights in RFC | Information on the procedures with respect to rights in RFC | |||
documents can be found in BCP 78 and BCP 79. | documents can be found in BCP 78 and BCP 79. | |||
skipping to change at page 20, line 4 | skipping to change at page 20, line 43 | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at ietf- | |||
ipr@ietf.org. | ipr@ietf.org. | |||
The IETF has been notified by Tellabs Operations, Inc. of | The IETF has been notified by Tellabs Operations, Inc. of | |||
intellectual property rights claimed in regard to some or all of | intellectual property rights claimed in regard to some or all of | |||
the specification contained in this document. For more information, | the specification contained in this document. For more information, | |||
draft-ietf-ccamp-gmpls-mln-reqs-00.txt January 2006 | ||||
see http://www.ietf.org/ietf/IPR/tellabs-ipr-draft-shiomoto-ccamp- | see http://www.ietf.org/ietf/IPR/tellabs-ipr-draft-shiomoto-ccamp- | |||
gmpls-mrn-reqs.txt | gmpls-mrn-reqs.txt | |||
11. Full Copyright Statement | 10. Full Copyright Statement | |||
Copyright (C) The Internet Society (2006). This document is subject | Copyright (C) The Internet Society (2006). This document is subject | |||
to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
This document and the information contained herein are provided on | This document and the information contained herein are provided on | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND | |||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | |||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | |||
End of changes. 117 change blocks. | ||||
370 lines changed or deleted | 365 lines changed or added | |||
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |