draft-ietf-mpls-cr-ldp-04.txt | draft-ietf-mpls-cr-ldp-05.txt | |||
---|---|---|---|---|
MPLS Working Group Bilel Jamoussi, Editor | MPLS Working Group Bilel Jamoussi, Editor | |||
Internet Draft Nortel Networks Corp. | Internet Draft Nortel Networks Corp. | |||
Expiration Date: January 2001 | Expiration Date: August 2001 | |||
O. Aboul-Magd, L. Andersson, P. Ashwood-Smith, | O. Aboul-Magd, L. Andersson, P. Ashwood-Smith, | |||
F. Hellstrand, K. Sundell, Nortel Networks Corp. | F. Hellstrand, K. Sundell, Nortel Networks Corp. | |||
R. Callon, Juniper Networks. | R. Callon, Juniper Networks. | |||
R. Dantu, IPmobile | R. Dantu, L. Wu, Cisco Systems | |||
P. Doolan, T. Worster, Ennovate Networks Corp. | P. Doolan, T. Worster, Ennovate Networks Corp. | |||
N. Feldman, IBM Corp. | N. Feldman, IBM Corp. | |||
A. Fredette, PhotonEx Corp. | A. Fredette, PhotonEx Corp. | |||
M. Girish, Atoga Systems | M. Girish, Atoga Systems | |||
E. Gray, Zaffire, Inc. | E. Gray, Sandburst | |||
J. Halpern, Longitude Systems, Inc. | J. Halpern, Longitude Systems, Inc. | |||
J. Heinanen, Telia Finland | J. Heinanen, Telia Finland | |||
T. Kilty, Newbridge Networks, Inc. | T. Kilty, Newbridge Networks, Inc. | |||
A. Malis, Vivace Networks | A. Malis, Vivace Networks | |||
P. Vaananen, Nokia Telecommunications | P. Vaananen, Nokia Telecommunications | |||
L. Wu, Cisco Systems | ||||
July 2000 | February 2001 | |||
Constraint-Based LSP Setup using LDP | Constraint-Based LSP Setup using LDP | |||
draft-ietf-mpls-cr-ldp-04.txt | draft-ietf-mpls-cr-ldp-05.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
at any time. It is inappropriate to use Internet-Drafts as reference | at any time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as _work in progress._ | material or to cite them other than as "work in progress.ö | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Abstract | Abstract | |||
Label Distribution Protocol (LDP) is defined in [1] for distribution | Label Distribution Protocol (LDP) is defined in [1] for distribution | |||
of labels inside one MPLS domain. One of the most important | of labels inside one MPLS domain. One of the most important | |||
services that may be offered using MPLS in general and LDP in | services that may be offered using MPLS in general and LDP in | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 1Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
particular is support for constraint-based routing of traffic across | particular is support for constraint-based routing of traffic across | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 1 | ||||
the routed network. Constraint-based routing offers the opportunity | the routed network. Constraint-based routing offers the opportunity | |||
to extend the information used to setup paths beyond what is | to extend the information used to setup paths beyond what is | |||
available for the routing protocol. For instance, an LSP can be | available for the routing protocol. For instance, an LSP can be | |||
setup based on explicit route constraints, QoS constraints, and | setup based on explicit route constraints, QoS constraints, and | |||
other constraints. Constraint-based routing (CR) is a mechanism used | other constraints. Constraint-based routing (CR) is a mechanism used | |||
to meet Traffic Engineering requirements that have been proposed by | to meet Traffic Engineering requirements that have been proposed by, | |||
[2], [3] and [4]. These requirements may be met by extending LDP for | [2] and [3]. These requirements may be met by extending LDP for | |||
support of constraint-based routed label switched paths (CR-LSPs). | support of constraint-based routed label switched paths (CR-LSPs). | |||
Other uses for CR-LSPs include MPLS-based VPNs [5]. More information | Other uses for CR-LSPs include MPLS-based VPNs [4]. More information | |||
about the applicability of CR-LDP can be found in [6]. | about the applicability of CR-LDP can be found in [5]. | |||
This draft specifies mechanisms and TLVs for support of CR-LSPs | This draft specifies mechanisms and TLVs for support of CR-LSPs | |||
using LDP. | using LDP. | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | |||
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" | |||
in this document are to be interpreted as described in RFC 2119 [7]. | in this document are to be interpreted as described in RFC 2119 [6]. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 2Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 2 | ||||
Table of Contents | Table of Contents | |||
1. Introduction....................................................4 | 1. Introduction....................................................4 | |||
2. Constraint-based Routing Overview...............................4 | 2. Constraint-based Routing Overview...............................4 | |||
2.1 Strict and Loose Explicit Routes...............................5 | 2.1 Strict and Loose Explicit Routes...............................5 | |||
2.2 Traffic Characteristics........................................5 | 2.2 Traffic Characteristics........................................5 | |||
2.3 Pre-emption....................................................6 | 2.3 Pre-emption....................................................6 | |||
2.4 Route Pinning..................................................6 | 2.4 Route Pinning..................................................6 | |||
2.5 Resource Class.................................................6 | 2.5 Resource Class.................................................6 | |||
3. Solution Overview...............................................7 | 3. Solution Overview...............................................6 | |||
3.1 Required Messages and TLVs.....................................8 | 3.1 Required Messages and TLVs.....................................8 | |||
3.2 Label Request Message..........................................8 | 3.2 Label Request Message..........................................8 | |||
3.3 Label Mapping Message..........................................9 | 3.3 Label Mapping Message..........................................9 | |||
3.4 Notification Message..........................................10 | 3.4 Notification Message...........................................9 | |||
3.5 Release , Withdraw, and Abort Messages........................10 | 3.5 Release , Withdraw, and Abort Messages........................10 | |||
4. Protocol Specification.........................................10 | 4. Protocol Specification.........................................10 | |||
4.1 Explicit Route TLV (ER-TLV)...................................11 | 4.1 Explicit Route TLV (ER-TLV)...................................11 | |||
4.2 Explicit Route Hop TLV (ER-Hop TLV)...........................11 | 4.2 Explicit Route Hop TLV (ER-Hop TLV)...........................11 | |||
4.3 Traffic Parameters TLV........................................12 | 4.3 Traffic Parameters TLV........................................12 | |||
4.3.1 Semantics...................................................14 | 4.3.1 Semantics...................................................14 | |||
4.3.1.1 Frequency.................................................14 | 4.3.1.1 Frequency.................................................14 | |||
4.3.1.2 Peak Rate.................................................14 | 4.3.1.2 Peak Rate.................................................14 | |||
4.3.1.3 Committed Rate............................................15 | 4.3.1.3 Committed Rate............................................14 | |||
4.3.1.4 Excess Burst Size.........................................15 | 4.3.1.4 Excess Burst Size.........................................15 | |||
4.3.1.5 Peak Rate Token Bucket....................................15 | 4.3.1.5 Peak Rate Token Bucket....................................15 | |||
4.3.1.6 Committed Data Rate Token Bucket..........................15 | 4.3.1.6 Committed Data Rate Token Bucket..........................15 | |||
4.3.1.7 Weight....................................................16 | 4.3.1.7 Weight....................................................16 | |||
4.3.2 Procedures..................................................16 | 4.3.2 Procedures..................................................16 | |||
4.3.2.1 Label Request Message.....................................16 | 4.3.2.1 Label Request Message.....................................16 | |||
4.3.2.2 Label Mapping Message.....................................17 | 4.3.2.2 Label Mapping Message.....................................17 | |||
4.3.2.3 Notification Message......................................17 | 4.3.2.3 Notification Message......................................17 | |||
4.4 Preemption TLV................................................17 | 4.4 Preemption TLV................................................17 | |||
4.5 LSPID TLV.....................................................18 | 4.5 LSPID TLV.....................................................18 | |||
4.6 Resource Class (Color) TLV....................................20 | 4.6 Resource Class (Color) TLV....................................20 | |||
4.7 ER-Hop semantics..............................................20 | 4.7 ER-Hop semantics..............................................20 | |||
4.7.1. ER-Hop 1: The IPv4 prefix..................................20 | 4.7.1. ER-Hop 1: The IPv4 prefix..................................20 | |||
4.7.2. ER-Hop 2: The IPv6 address.................................21 | 4.7.2. ER-Hop 2: The IPv6 address.................................21 | |||
4.7.3. ER-Hop 3: The autonomous system number....................22 | 4.7.3. ER-Hop 3: The autonomous system number....................21 | |||
4.7.4. ER-Hop 4: LSPID............................................22 | 4.7.4. ER-Hop 4: LSPID............................................22 | |||
4.8. Processing of the Explicit Route TLV.........................23 | 4.8. Processing of the Explicit Route TLV.........................23 | |||
4.8.1. Selection of the next hop..................................23 | 4.8.1. Selection of the next hop..................................23 | |||
4.8.2. Adding ER-Hops to the explicit route TLV...................25 | 4.8.2. Adding ER-Hops to the explicit route TLV...................25 | |||
4.9 Route Pinning TLV.............................................25 | 4.9 Route Pinning TLV.............................................25 | |||
4.10 CR-LSP FEC Element...........................................26 | 4.10 CR-LSP FEC Element...........................................26 | |||
4.11 TLV Type Summary.............................................26 | 5. IANA Considerations............................................26 | |||
4.12 FEC Type Summary.............................................27 | 5.1 TLV Type Name Space...........................................26 | |||
4.13 Status Code Summary..........................................27 | ||||
5. IANA Considerations............................................27 | ||||
5.1 TLV Type Name Space...........................................27 | ||||
5.2 FEC Type Name Space...........................................27 | 5.2 FEC Type Name Space...........................................27 | |||
5.3 Status Code Space.............................................27 | 5.3 Status Code Space.............................................27 | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 3Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
6. Security.......................................................28 | 6. Security.......................................................28 | |||
7. Acknowledgments................................................28 | 7. Acknowledgments................................................28 | |||
8. Intellectual Property Consideration............................28 | 8. Intellectual Property Consideration............................28 | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 3 | ||||
9. References.....................................................28 | 9. References.....................................................28 | |||
10. Author's Addresses............................................29 | 10. AuthorÆs Addresses............................................29 | |||
Appendix A: CR-LSP Establishment Examples.........................31 | Appendix A: CR-LSP Establishment Examples.........................31 | |||
A.1 Strict Explicit Route Example.................................31 | A.1 Strict Explicit Route Example.................................31 | |||
A.2 Node Groups and Specific Nodes Example........................32 | A.2 Node Groups and Specific Nodes Example........................32 | |||
Appendix B. QoS Service Examples..................................35 | Appendix B. QoS Service Examples..................................35 | |||
B.1 Service Examples..............................................35 | B.1 Service Examples..............................................35 | |||
B.2 Establishing CR-LSP Supporting Real-Time Applications.........36 | B.2 Establishing CR-LSP Supporting Real-Time Applications.........36 | |||
B.3 Establishing CR-LSP Supporting Delay Insensitive Applications.37 | B.3 Establishing CR-LSP Supporting Delay Insensitive Applications.37 | |||
1. Introduction | 1. Introduction | |||
The need for constraint-based routing (CR) in MPLS has been explored | The need for constraint-based routing (CR) in MPLS has been explored | |||
elsewhere [3], [2], and [4]. Explicit routing is a subset of the | elsewhere [2], and [3]. Explicit routing is a subset of the more | |||
more general constraint-based routing function. At the MPLS WG | general constraint-based routing function. At the MPLS WG meeting | |||
meeting held during the Washington IETF (December 1997) there was | held during the Washington IETF (December 1997) there was consensus | |||
consensus that LDP should support explicit routing of LSPs with | that LDP should support explicit routing of LSPs with provision for | |||
provision for indication of associated (forwarding) priority. In | indication of associated (forwarding) priority. In the Chicago | |||
the Chicago meeting (August 1998), a decision was made that support | meeting (August 1998), a decision was made that support for explicit | |||
for explicit path setup in LDP will be moved to a separate document. | path setup in LDP will be moved to a separate document. This | |||
This document provides that support and it has been accepted as a | document provides that support and it has been accepted as a working | |||
working document in the Orlando meeting (December 1998). | document in the Orlando meeting (December 1998). | |||
This specification proposes an end-to-end setup mechanism of a | This specification proposes an end-to-end setup mechanism of a | |||
constraint-based routed LSP (CR-LSP) initiated by the ingress LSR. | constraint-based routed LSP (CR-LSP) initiated by the ingress LSR. | |||
We also specify mechanisms to provide means for reservation of | We also specify mechanisms to provide means for reservation of | |||
resources using LDP. | resources using LDP. | |||
This document introduce TLVs and procedures that provide support | This document introduce TLVs and procedures that provide support | |||
for: | for: | |||
- Strict and Loose Explicit Routing | - Strict and Loose Explicit Routing | |||
- Specification of Traffic Parameters | - Specification of Traffic Parameters | |||
skipping to change at line 183 | skipping to change at line 176 | |||
Section 2 introduces the various constraints defined in this | Section 2 introduces the various constraints defined in this | |||
specification. Section 3 outlines the CR-LDP solution. Section 4 | specification. Section 3 outlines the CR-LDP solution. Section 4 | |||
defines the TLVs and procedures used to setup constraint-based | defines the TLVs and procedures used to setup constraint-based | |||
routed label switched paths. Appendix A provides several examples | routed label switched paths. Appendix A provides several examples | |||
of CR-LSP path setup. Appendix B provides Service Definition | of CR-LSP path setup. Appendix B provides Service Definition | |||
Examples. | Examples. | |||
2. Constraint-based Routing Overview | 2. Constraint-based Routing Overview | |||
Constraint-based routing is a mechanism that supports the Traffic | Constraint-based routing is a mechanism that supports the Traffic | |||
Engineering requirements defined in [3]. Explicit Routing is a | ||||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 4Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
Engineering requirements defined in [4]. Explicit Routing is a | ||||
subset of the more general constraint-based routing where the | subset of the more general constraint-based routing where the | |||
constraint is the explicit route (ER). Other constraints are defined | constraint is the explicit route (ER). Other constraints are defined | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 4 | ||||
to provide a network operator with control over the path taken by an | to provide a network operator with control over the path taken by an | |||
LSP. This section is an overview of the various constraints | LSP. This section is an overview of the various constraints | |||
supported by this specification. | supported by this specification. | |||
Like any other LSP a CR-LSP is a path through an MPLS network. The | Like any other LSP a CR-LSP is a path through an MPLS network. The | |||
difference is that while other paths are setup solely based on | difference is that while other paths are setup solely based on | |||
information in routing tables or from a management system, the | information in routing tables or from a management system, the | |||
constraint-based route is calculated at one point at the edge of | constraint-based route is calculated at one point at the edge of | |||
network based on criteria, including but not limited to routing | network based on criteria, including but not limited to routing | |||
information. The intention is that this functionality shall give | information. The intention is that this functionality shall give | |||
skipping to change at line 238 | skipping to change at line 230 | |||
To simplify the discussion, we call each group of nodes an abstract | To simplify the discussion, we call each group of nodes an abstract | |||
node. Thus, we can also say that a constraint-based route is a path | node. Thus, we can also say that a constraint-based route is a path | |||
including all of the abstract nodes, with the specified operations | including all of the abstract nodes, with the specified operations | |||
occurring along that path. | occurring along that path. | |||
2.2 Traffic Characteristics | 2.2 Traffic Characteristics | |||
The traffic characteristics of a path are described in the Traffic | The traffic characteristics of a path are described in the Traffic | |||
Parameters TLV in terms of a peak rate, committed rate, and service | Parameters TLV in terms of a peak rate, committed rate, and service | |||
granularity. The peak and committed rates describe the bandwidth | granularity. The peak and committed rates describe the bandwidth | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 5Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
constraints of a path while the service granularity can be used to | constraints of a path while the service granularity can be used to | |||
specify a constraint on the delay variation that the CR-LDP MPLS | specify a constraint on the delay variation that the CR-LDP MPLS | |||
domain may introduce to a path's traffic. | domain may introduce to a pathÆs traffic. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 5 | ||||
2.3 Pre-emption | 2.3 Pre-emption | |||
CR-LDP signals the resources required by a path on each hop of the | CR-LDP signals the resources required by a path on each hop of the | |||
route. If a route with sufficient resources can not be found, | route. If a route with sufficient resources can not be found, | |||
existing paths may be rerouted to reallocate resources to the new | existing paths may be rerouted to reallocate resources to the new | |||
path. This is the process of path pre-emption. Setup and holding | path. This is the process of path pre-emption. Setup and holding | |||
priorities are used to rank existing paths (holding priority) and | priorities are used to rank existing paths (holding priority) and | |||
the new path (setup priority) to determine if the new path can pre- | the new path (setup priority) to determine if the new path can pre- | |||
empt an existing path. | empt an existing path. | |||
skipping to change at line 276 | skipping to change at line 267 | |||
The setup and holding priority values range from zero (0) to seven | The setup and holding priority values range from zero (0) to seven | |||
(7). The value zero (0) is the priority assigned to the most | (7). The value zero (0) is the priority assigned to the most | |||
important path. It is referred to as the highest priority. Seven (7) | important path. It is referred to as the highest priority. Seven (7) | |||
is the priority for the least important path. The use of default | is the priority for the least important path. The use of default | |||
priority values is an aspect of network policy. The recommended | priority values is an aspect of network policy. The recommended | |||
default value is (4). | default value is (4). | |||
The setupPriority of a CR-LSP should not be higher (numerically | The setupPriority of a CR-LSP should not be higher (numerically | |||
less) than its holdingPriority since it might bump an LSP and be | less) than its holdingPriority since it might bump an LSP and be | |||
bumped by the next _equivalent_ request. | bumped by the next "equivalentö request. | |||
2.4 Route Pinning | 2.4 Route Pinning | |||
Route pinning is applicable to segments of an LSP that are loosely | Route pinning is applicable to segments of an LSP that are loosely | |||
routed - i.e. those segments which are specified with a next hop | routed - i.e. those segments which are specified with a next hop | |||
with the _L_ bit set or where the next hop is an _abstract node_. A | with the öLö bit set or where the next hop is an öabstract nodeö. A | |||
CR-LSP may be setup using route pinning if it is undesirable to | CR-LSP may be setup using route pinning if it is undesirable to | |||
change the path used by an LSP even when a better next hop becomes | change the path used by an LSP even when a better next hop becomes | |||
available at some LSR along the loosely routed portion of the LSP. | available at some LSR along the loosely routed portion of the LSP. | |||
2.5 Resource Class | 2.5 Resource Class | |||
The network operator may classify network resources in various ways. | The network operator may classify network resources in various ways. | |||
These classes are also known as _colors_ or _administrative groups_. | These classes are also known as "colorsö or "administrative groupsö. | |||
When a CR-LSP is being established, it's necessary to indicate which | When a CR-LSP is being established, itÆs necessary to indicate which | |||
resource classes the CR-LSP can draw from. | resource classes the CR-LSP can draw from. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 6Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
3. Solution Overview | 3. Solution Overview | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 6 | ||||
CR-LSP over LDP Specification is designed with the following goals: | CR-LSP over LDP Specification is designed with the following goals: | |||
1. Meet the requirements outlined in [4] for performing traffic | 1. Meet the requirements outlined in [3] for performing traffic | |||
engineering and provide a solid foundation for performing | engineering and provide a solid foundation for performing more | |||
more general constraint-based routing. | general constraint-based routing. | |||
2. Build on already specified functionality that meets the | 2. Build on already specified functionality that meets the | |||
requirements whenever possible. Hence, this specification is | requirements whenever possible. Hence, this specification is | |||
based on [1]. | based on [1]. | |||
3. Keep the solution simple. | 3. Keep the solution simple. | |||
In this document, support for unidirectional point-to-point CR-LSPs | In this document, support for unidirectional point-to-point CR-LSPs | |||
is specified. Support for point-to-multipoint, multipoint-to-point, | is specified. Support for point-to-multipoint, multipoint-to-point, | |||
is for further study (FFS). | is for further study (FFS). | |||
Support for constraint-based routed LSPs in this specification | Support for constraint-based routed LSPs in this specification | |||
depends on the following minimal LDP behaviors as specified in [1]: | depends on the following minimal LDP behaviors as specified in [1]: | |||
- Use of Basic and/or Extended Discovery Mechanisms. | - Use of Basic and/or Extended Discovery Mechanisms. | |||
- Use of the Label Request Message defined in [1] in downstream | - Use of the Label Request Message defined in [1] in downstream on | |||
on demand label advertisement mode with ordered control. | demand label advertisement mode with ordered control. | |||
- Use of the Label Mapping Message defined in [1] in downstream | - Use of the Label Mapping Message defined in [1] in downstream on | |||
on demand mode with ordered control. | demand mode with ordered control. | |||
- Use of the Notification Message defined in [1]. | - Use of the Notification Message defined in [1]. | |||
- Use of the Withdraw and Release Messages defined in [1]. | - Use of the Withdraw and Release Messages defined in [1]. | |||
- Use of the Loop Detection (in the case of loosely routed | - Use of the Loop Detection (in the case of loosely routed | |||
segments of a CR-LSP) mechanisms defined in [1]. | segments of a CR-LSP) mechanisms defined in [1]. | |||
In addition, the following functionality is added to what's defined | In addition, the following functionality is added to whatÆs defined | |||
in [1]: | in [1]: | |||
- The Label Request Message used to setup a CR-LSP includes one | - The Label Request Message used to setup a CR-LSP includes one or | |||
or more CR-TLVs defined in Section 4. For instance, the Label | more CR-TLVs defined in Section 4. For instance, the Label Request | |||
Request Message may include the ER-TLV. | Message may include the ER-TLV. | |||
- An LSR implicitly infers ordered control from the existence of | - An LSR implicitly infers ordered control from the existence of | |||
one or more CR-TLVs in the Label Request Message. This means | one or more CR-TLVs in the Label Request Message. This means that | |||
that the LSR can still be configured for independent control | the LSR can still be configured for independent control for LSPs | |||
for LSPs established as a result of dynamic routing. However, | established as a result of dynamic routing. However, when a Label | |||
when a Label Request Message includes one or more of the CR- | Request Message includes one or more of the CR-TLVs, then ordered | |||
TLVs, then ordered control is used to setup the CR-LSP. Note | control is used to setup the CR-LSP. Note that this is also true | |||
that this is also true for the loosely routed parts of a CR- | for the loosely routed parts of a CR-LSP. | |||
LSP. | ||||
- New status codes are defined to handle error notification for | - New status codes are defined to handle error notification for | |||
failure of established paths specified in the CR-TLVs. | failure of established paths specified in the CR-TLVs. | |||
Optional TLVs MUST be implemented to be compliant with the protocol. | Optional TLVs MUST be implemented to be compliant with the protocol. | |||
However, they are optionally carried in the CR-LDP messages to | However, they are optionally carried in the CR-LDP messages to | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 7Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
signal certain characteristics of the CR-LSP being established or | signal certain characteristics of the CR-LSP being established or | |||
modified. | modified. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 7 | ||||
Examples of CR-LSP establishment are given in Appendix A to | Examples of CR-LSP establishment are given in Appendix A to | |||
illustrate how the mechanisms described in this draft work. | illustrate how the mechanisms described in this draft work. | |||
3.1 Required Messages and TLVs | 3.1 Required Messages and TLVs | |||
Any Messages, TLVs, and procedures not defined explicitly in this | Any Messages, TLVs, and procedures not defined explicitly in this | |||
document are defined in the LDP Specification [1]. The reader can | document are defined in the LDP Specification [1]. The reader can | |||
use [8] as an informational document about the state transitions, | use [7] as an informational document about the state transitions, | |||
which relate to CR-LDP messages. | which relate to CR-LDP messages. | |||
The following subsections are meant as a cross-reference to the [1] | The following subsections are meant as a cross-reference to the [1] | |||
document and indication of additional functionality beyond what's | document and indication of additional functionality beyond whatÆs | |||
defined in [1] where necessary. | defined in [1] where necessary. | |||
Note that use of the Status TLV is not limited to Notification | Note that use of the Status TLV is not limited to Notification | |||
messages as specified in Section 3.4.6 of [1]. A message other than | messages as specified in Section 3.4.6 of [1]. A message other than | |||
a Notification message may carry a Status TLV as an Optional | a Notification message may carry a Status TLV as an Optional | |||
Parameter. When a message other than a Notification carries a | Parameter. When a message other than a Notification carries a | |||
Status TLV the U-bit of the Status TLV should be set to 1 to | Status TLV the U-bit of the Status TLV should be set to 1 to | |||
indicate that the receiver should silently discard the TLV if | indicate that the receiver should silently discard the TLV if | |||
unprepared to handle it. | unprepared to handle it. | |||
3.2 Label Request Message | 3.2 Label Request Message | |||
The Label Request Message is as defined in 3.5.8 of [1] with the | The Label Request Message is as defined in 3.5.8 of [1] with the | |||
following modifications (required only if any of the CR-TLVs is | following modifications (required only if any of the CR-TLVs is | |||
included in the Label Request Message): | included in the Label Request Message): | |||
- The Label Request Message MUST include a single FEC-TLV | - The Label Request Message MUST include a single FEC-TLV element. | |||
element. The CR-LSP FEC TLV element SHOULD be used. However, | The CR-LSP FEC TLV element SHOULD be used. However, the other FEC- | |||
the other FEC-TLVs defined in [1] MAY be used instead for | TLVs defined in [1] MAY be used instead for certain applications. | |||
certain applications. | ||||
- The Optional Parameters TLV includes the definition of any of | - The Optional Parameters TLV includes the definition of any of | |||
the Constraint-based TLVs specified in Section 4. | the Constraint-based TLVs specified in Section 4. | |||
- The Procedures to handle the Label Request Message are | - The Procedures to handle the Label Request Message are augmented | |||
augmented by the procedures for processing of the CR-TLVs as | by the procedures for processing of the CR-TLVs as defined in | |||
defined in Section 4. | Section 4. | |||
The encoding for the CR-LDP Label Request Message is as follows: | The encoding for the CR-LDP Label Request Message is as follows: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0| Label Request (0x0401) | Message Length | | |0| Label Request (0x0401) | Message Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Message ID | | | Message ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 8Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
| FEC TLV | | | FEC TLV | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| LSPID TLV (CR-LDP, mandatory) | | | LSPID TLV (CR-LDP, mandatory) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 8 | ||||
| ER-TLV (CR-LDP, optional) | | | ER-TLV (CR-LDP, optional) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Traffic TLV (CR-LDP, optional) | | | Traffic TLV (CR-LDP, optional) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Pinning TLV (CR-LDP, optional) | | | Pinning TLV (CR-LDP, optional) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Resource Class TLV (CR-LDP, optional) | | | Resource Class TLV (CR-LDP, optional) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Pre-emption TLV (CR-LDP, optional) | | | Pre-emption TLV (CR-LDP, optional) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at line 436 | skipping to change at line 423 | |||
- The Label Mapping Message Procedures are limited to downstream | - The Label Mapping Message Procedures are limited to downstream | |||
on demand ordered control mode. | on demand ordered control mode. | |||
A Mapping message is transmitted by a downstream LSR to an upstream | A Mapping message is transmitted by a downstream LSR to an upstream | |||
LSR under one of the following conditions: | LSR under one of the following conditions: | |||
1. The LSR is the egress end of the CR-LSP and an upstream | 1. The LSR is the egress end of the CR-LSP and an upstream | |||
mapping has been requested. | mapping has been requested. | |||
2. The LSR received a mapping from its downstream next hop LSR | 2. The LSR received a mapping from its downstream next hop LSR | |||
for an CR-LSP for which an upstream request is still | for an CR-LSP for which an upstream request is still pending. | |||
pending. | ||||
The encoding for the CR-LDP Label Mapping Message is as follows: | The encoding for the CR-LDP Label Mapping Message is as follows: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0| Label Mapping (0x0400) | Message Length | | |0| Label Mapping (0x0400) | Message Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Message ID | | | Message ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| FEC TLV | | | FEC TLV | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Label TLV | | | Label TLV | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Label Request Message ID TLV | | | Label Request Message ID TLV | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| LSPID TLV (CR-LDP, optional) | | | LSPID TLV (CR-LDP, optional) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 9Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
| Traffic TLV (CR-LDP, optional) | | | Traffic TLV (CR-LDP, optional) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
3.4 Notification Message | 3.4 Notification Message | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 9 | ||||
The Notification Message is as defined in Section 3.5.1 of [1] and | The Notification Message is as defined in Section 3.5.1 of [1] and | |||
the Status TLV encoding is as defined in Section 3.4.6 of [1]. | the Status TLV encoding is as defined in Section 3.4.6 of [1]. | |||
Establishment of an CR-LSP may fail for a variety of reasons. All | Establishment of an CR-LSP may fail for a variety of reasons. All | |||
such failures are considered advisory conditions and they are | such failures are considered advisory conditions and they are | |||
signaled by the Notification Message. | signaled by the Notification Message. | |||
Notification Messages carry Status TLVs to specify events being | Notification Messages carry Status TLVs to specify events being | |||
signaled. New status codes are defined in Section 4.11 to signal | signaled. New status codes are defined in Section 4.11 to signal | |||
error notifications associated with the establishment of a CR-LSP | error notifications associated with the establishment of a CR-LSP | |||
and the processing of the CR-TLV. | and the processing of the CR-TLV. | |||
skipping to change at line 511 | skipping to change at line 495 | |||
LSPID TLV. | LSPID TLV. | |||
4. Protocol Specification | 4. Protocol Specification | |||
The Label Request Message defined in [1] MUST carry the LSPID TLV | The Label Request Message defined in [1] MUST carry the LSPID TLV | |||
and MAY carry one or more of the optional Constraint-based Routing | and MAY carry one or more of the optional Constraint-based Routing | |||
TLVs (CR-TLVs) defined in this section. If needed, other constraints | TLVs (CR-TLVs) defined in this section. If needed, other constraints | |||
can be supported later through the definition of new TLVs. In this | can be supported later through the definition of new TLVs. In this | |||
specification, the following TLVs are defined: | specification, the following TLVs are defined: | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 10Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
- Explicit Route TLV | - Explicit Route TLV | |||
- Explicit Route Hop TLV | - Explicit Route Hop TLV | |||
- Traffic Parameters TLV | - Traffic Parameters TLV | |||
- Preemption TLV | - Preemption TLV | |||
- LSPID TLV | - LSPID TLV | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 10 | ||||
- Route Pinning TLV | - Route Pinning TLV | |||
- Resource Class TLV | - Resource Class TLV | |||
- CR-LSP FEC TLV | - CR-LSP FEC TLV | |||
4.1 Explicit Route TLV (ER-TLV) | 4.1 Explicit Route TLV (ER-TLV) | |||
The ER-TLV is an object that specifies the path to be taken by the | The ER-TLV is an object that specifies the path to be taken by the | |||
LSP being established. It is composed of one or more Explicit Route | LSP being established. It is composed of one or more Explicit Route | |||
Hop TLVs (ER-Hop TLVs) defined in Section 4.2. | Hop TLVs (ER-Hop TLVs) defined in Section 4.2. | |||
skipping to change at line 559 | skipping to change at line 543 | |||
ER-Hop TLVs | ER-Hop TLVs | |||
One or more ER-Hop TLVs defined in Section 4.2. | One or more ER-Hop TLVs defined in Section 4.2. | |||
4.2 Explicit Route Hop TLV (ER-Hop TLV) | 4.2 Explicit Route Hop TLV (ER-Hop TLV) | |||
The contents of an ER-TLV are a series of variable length ER-Hop | The contents of an ER-TLV are a series of variable length ER-Hop | |||
TLVs. | TLVs. | |||
A node receiving a label request message including an ER-Hop type | A node receiving a label request message including an ER-Hop type | |||
that is not supported MUST not progress the label request message to | that is not supported MUST not progress the label request message to | |||
the downstream LSR and MUST send back a _No Route_ Notification | the downstream LSR and MUST send back a "No Routeö Notification | |||
Message. | Message. | |||
Each ER-Hop TLV has the form: | Each ER-Hop TLV has the form: | |||
0 1 2 3 | 0 1 2 3 | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 11Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0|0| Type | Length | | |0|0| Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L| Content // | | |L| Content // | | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 11 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
ER-Hop Type | ER-Hop Type | |||
A fourteen-bit field carrying the type of the ER-Hop contents. | A fourteen-bit field carrying the type of the ER-Hop contents. | |||
Currently defined values are: | Currently defined values are: | |||
Value Type | Value Type | |||
------ ------------------------ | ------ ------------------------ | |||
0x0801 IPv4 prefix | 0x0801 IPv4 prefix | |||
0x0802 IPv6 prefix | 0x0802 IPv6 prefix | |||
0x0803 Autonomous system number | 0x0803 Autonomous system number | |||
0x0804 LSPID | 0x0804 LSPID | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
L bit | L bit | |||
The L bit in the ER-Hop is a one-bit attribute. If the L bit | The L bit in the ER-Hop is a one-bit attribute. If the L bit | |||
is set, then the value of the attribute is _loose._ Otherwise, | is set, then the value of the attribute is "loose.ö Otherwise, | |||
the value of the attribute is _strict._ For brevity, we say | the value of the attribute is "strict.ö For brevity, we say | |||
that if the value of the ER-Hop attribute is loose then it is a | that if the value of the ER-Hop attribute is loose then it is a | |||
_loose ER-Hop._ Otherwise, it's a _strict ER-Hop._ Further, | "loose ER-Hop.ö Otherwise, itÆs a "strict ER-Hop.ö Further, | |||
we say that the abstract node of a strict or loose ER-Hop is a | we say that the abstract node of a strict or loose ER-Hop is a | |||
strict or a loose node, respectively. Loose and strict nodes | strict or a loose node, respectively. Loose and strict nodes | |||
are always interpreted relative to their prior abstract nodes. | are always interpreted relative to their prior abstract nodes. | |||
The path between a strict node and its prior node MUST include | The path between a strict node and its prior node MUST include | |||
only network nodes from the strict node and its prior abstract | only network nodes from the strict node and its prior abstract | |||
node. | node. | |||
The path between a loose node and its prior node MAY include | The path between a loose node and its prior node MAY include | |||
other network nodes, which are not part of the strict node or | other network nodes, which are not part of the strict node or | |||
its prior abstract node. | its prior abstract node. | |||
skipping to change at line 621 | skipping to change at line 604 | |||
4.3 Traffic Parameters TLV | 4.3 Traffic Parameters TLV | |||
The following sections describe the CR-LSP Traffic Parameters. The | The following sections describe the CR-LSP Traffic Parameters. The | |||
required characteristics of a CR-LSP are expressed by the Traffic | required characteristics of a CR-LSP are expressed by the Traffic | |||
Parameter values. | Parameter values. | |||
A Traffic Parameters TLV, is used to signal the Traffic Parameter | A Traffic Parameters TLV, is used to signal the Traffic Parameter | |||
values. The Traffic Parameters are defined in the subsequent | values. The Traffic Parameters are defined in the subsequent | |||
sections. | sections. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 12Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
The Traffic Parameters TLV contains a Flags field, a Frequency, a | The Traffic Parameters TLV contains a Flags field, a Frequency, a | |||
Weight, and the five Traffic Parameters PDR, PBS, CDR, CBS, EBS. | Weight, and the five Traffic Parameters PDR, PBS, CDR, CBS, EBS. | |||
The Traffic Parameters TLV is shown below: | The Traffic Parameters TLV is shown below: | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 12 | ||||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0|0| Type = 0x0810 | Length = 24 | | |0|0| Type = 0x0810 | Length = 24 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Flags | Frequency | Reserved | Weight | | | Flags | Frequency | Reserved | Weight | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Peak Data Rate (PDR) | | | Peak Data Rate (PDR) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Peak Burst Size (PBS) | | | Peak Burst Size (PBS) | | |||
skipping to change at line 674 | skipping to change at line 656 | |||
F3 - Corresponds to the CDR. | F3 - Corresponds to the CDR. | |||
F4 - Corresponds to the CBS. | F4 - Corresponds to the CBS. | |||
F5 - Corresponds to the EBS. | F5 - Corresponds to the EBS. | |||
F6 - Corresponds to the Weight. | F6 - Corresponds to the Weight. | |||
Each flag Fi is a Negotiable Flag corresponding to a Traffic | Each flag Fi is a Negotiable Flag corresponding to a Traffic | |||
Parameter. The Negotiable Flag value zero denotes NotNegotiable | Parameter. The Negotiable Flag value zero denotes NotNegotiable | |||
and value one denotes Negotiable. | and value one denotes Negotiable. | |||
Frequency | Frequency | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 13Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
The Frequency field is coded as an 8 bit unsigned integer with | The Frequency field is coded as an 8 bit unsigned integer with | |||
the following code points defined: | the following code points defined: | |||
0- Unspecified | 0- Unspecified | |||
1- Frequent | 1- Frequent | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 13 | ||||
2- VeryFrequent | 2- VeryFrequent | |||
3-255 - Reserved | 3-255 - Reserved | |||
Reserved - Zero on transmission. Ignored on receipt. | Reserved - Zero on transmission. Ignored on receipt. | |||
Weight | Weight | |||
An 8 bit unsigned integer indicating the weight of the CR-LSP. | An 8 bit unsigned integer indicating the weight of the CR-LSP. | |||
Valid weight values are from 1 to 255. The value 0 means that | Valid weight values are from 1 to 255. The value 0 means that | |||
weight is not applicable for the CR-LSP. | weight is not applicable for the CR-LSP. | |||
Traffic Parameters | Traffic Parameters | |||
skipping to change at line 730 | skipping to change at line 711 | |||
The Peak Rate defines the maximum rate at which traffic SHOULD be | The Peak Rate defines the maximum rate at which traffic SHOULD be | |||
sent to the CR-LSP. The Peak Rate is useful for the purpose of | sent to the CR-LSP. The Peak Rate is useful for the purpose of | |||
resource allocation. If resource allocation within the MPLS domain | resource allocation. If resource allocation within the MPLS domain | |||
depends on the Peak Rate value then it should be enforced at the | depends on the Peak Rate value then it should be enforced at the | |||
ingress to the MPLS domain. | ingress to the MPLS domain. | |||
The Peak Rate is defined in terms of the two Traffic Parameters PDR | The Peak Rate is defined in terms of the two Traffic Parameters PDR | |||
and PBS, see section 4.3.1.5 below. | and PBS, see section 4.3.1.5 below. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 14Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
4.3.1.3 Committed Rate | 4.3.1.3 Committed Rate | |||
The Committed Rate defines the rate that the MPLS domain commits to | The Committed Rate defines the rate that the MPLS domain commits to | |||
be available to the CR-LSP. | be available to the CR-LSP. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 14 | ||||
The Committed Rate is defined in terms of the two Traffic Parameters | The Committed Rate is defined in terms of the two Traffic Parameters | |||
CDR and CBS, see section 4.3.1.6 below. | CDR and CBS, see section 4.3.1.6 below. | |||
4.3.1.4 Excess Burst Size | 4.3.1.4 Excess Burst Size | |||
The Excess Burst Size may be used at the edge of an MPLS domain for | The Excess Burst Size may be used at the edge of an MPLS domain for | |||
the purpose of traffic conditioning. The EBS MAY be used to measure | the purpose of traffic conditioning. The EBS MAY be used to measure | |||
the extent by which the traffic sent on a CR-LSP exceeds the | the extent by which the traffic sent on a CR-LSP exceeds the | |||
committed rate. | committed rate. | |||
skipping to change at line 773 | skipping to change at line 753 | |||
- If Tp(t)-B >= 0, the packet is not in excess of the peak rate | - If Tp(t)-B >= 0, the packet is not in excess of the peak rate | |||
and Tp is decremented by B down to the minimum value of 0, else | and Tp is decremented by B down to the minimum value of 0, else | |||
- the packet is in excess of the peak rate and Tp is not | - the packet is in excess of the peak rate and Tp is not | |||
decremented. | decremented. | |||
Note that according to the above definition, a positive infinite | Note that according to the above definition, a positive infinite | |||
value of either PDR or PBS implies that arriving packets are never | value of either PDR or PBS implies that arriving packets are never | |||
in excess of the peak rate. | in excess of the peak rate. | |||
The actual implementation of an LSR doesn't need to be modeled | The actual implementation of an LSR doesnÆt need to be modeled | |||
according to the above formal token bucket specification. | according to the above formal token bucket specification. | |||
4.3.1.6 Committed Data Rate Token Bucket | 4.3.1.6 Committed Data Rate Token Bucket | |||
The committed rate of a CR-LSP is specified in terms of a token | The committed rate of a CR-LSP is specified in terms of a token | |||
bucket C with rate CDR. The extent by which the offered rate | bucket C with rate CDR. The extent by which the offered rate | |||
exceeds the committed rate MAY be measured in terms of another token | exceeds the committed rate MAY be measured in terms of another token | |||
bucket E, which also operates at rate CDR. The maximum size of the | bucket E, which also operates at rate CDR. The maximum size of the | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 15Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
token bucket C is CBS and the maximum size of the token bucket E is | token bucket C is CBS and the maximum size of the token bucket E is | |||
EBS. | EBS. | |||
The token buckets C and E are initially (at time 0) full, i.e., the | The token buckets C and E are initially (at time 0) full, i.e., the | |||
token count Tc(0) = CBS and the token count Te(0) = EBS. | token count Tc(0) = CBS and the token count Te(0) = EBS. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 15 | ||||
Thereafter, the token counts Tc and Te are updated CDR times per | Thereafter, the token counts Tc and Te are updated CDR times per | |||
second as follows: | second as follows: | |||
- If Tc is less than CBS, Tc is incremented by one, else | - If Tc is less than CBS, Tc is incremented by one, else | |||
- if Te is less then EBS, Te is incremented by one, else | - if Te is less then EBS, Te is incremented by one, else | |||
- neither Tc nor Te is incremented. | neither Tc nor Te is incremented. | |||
When a packet of size B bytes arrives at time t, the following | When a packet of size B bytes arrives at time t, the following | |||
happens: | happens: | |||
- If Tc(t)-B >= 0, the packet is not in excess of the Committed | - If Tc(t)-B >= 0, the packet is not in excess of the Committed | |||
Rate and Tc is decremented by B down to the minimum value of 0, | Rate and Tc is decremented by B down to the minimum value of 0, | |||
else | else | |||
- if Te(t)-B >= 0, the packet is in excess of the Committed rate | - if Te(t)-B >= 0, the packet is in excess of the Committed rate | |||
but is not in excess of the EBS and Te is decremented by B down | but is not in excess of the EBS and Te is decremented by B down to | |||
to the minimum value of 0, else | the minimum value of 0, else | |||
- the packet is in excess of both the Committed Rate and the EBS | - the packet is in excess of both the Committed Rate and the EBS | |||
and neither Tc nor Te is decremented. | and neither Tc nor Te is decremented. | |||
Note that according to the above specification, a CDR value of | Note that according to the above specification, a CDR value of | |||
positive infinity implies that arriving packets are never in excess | positive infinity implies that arriving packets are never in excess | |||
of either the Committed Rate or EBS. A positive infinite value of | of either the Committed Rate or EBS. A positive infinite value of | |||
either CBS or EBS implies that the respective limit cannot be | either CBS or EBS implies that the respective limit cannot be | |||
exceeded. | exceeded. | |||
The actual implementation of an LSR doesn't need to be modeled | The actual implementation of an LSR doesnÆt need to be modeled | |||
according to the above formal specification. | according to the above formal specification. | |||
4.3.1.7 Weight | 4.3.1.7 Weight | |||
The weight determines the CR-LSP's relative share of the possible | The weight determines the CR-LSPÆs relative share of the possible | |||
excess bandwidth above its committed rate. The definition of | excess bandwidth above its committed rate. The definition of | |||
_relative share_ is MPLS domain specific. | "relative shareö is MPLS domain specific. | |||
4.3.2 Procedures | 4.3.2 Procedures | |||
4.3.2.1 Label Request Message | 4.3.2.1 Label Request Message | |||
If an LSR receives an incorrectly encoded Traffic Parameters TLV in | If an LSR receives an incorrectly encoded Traffic Parameters TLV in | |||
which the value of PDR is less than the value of CDR then it MUST | which the value of PDR is less than the value of CDR then it MUST | |||
send a Notification Message including the Status code _Traffic | send a Notification Message including the Status code "Traffic | |||
Parameters Unavailable_ to the upstream LSR from which it received | Parameters Unavailableö to the upstream LSR from which it received | |||
the erroneous message. | the erroneous message. | |||
If a Traffic Parameter is indicated as Negotiable in the Label | If a Traffic Parameter is indicated as Negotiable in the Label | |||
Request Message by the corresponding Negotiable Flag then an LSR MAY | Request Message by the corresponding Negotiable Flag then an LSR MAY | |||
replace the Traffic Parameter value with a smaller value. | replace the Traffic Parameter value with a smaller value. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 16Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 16 | |||
If the Weight is indicated as Negotiable in the Label Request | If the Weight is indicated as Negotiable in the Label Request | |||
Message by the corresponding Negotiable Flag then an LSR may replace | Message by the corresponding Negotiable Flag then an LSR may replace | |||
the Weight value with a lower value (down to 0). | the Weight value with a lower value (down to 0). | |||
If, after possible Traffic Parameter negotiation, an LSR can support | If, after possible Traffic Parameter negotiation, an LSR can support | |||
the CR-LSP Traffic Parameters then the LSR MUST reserve the | the CR-LSP Traffic Parameters then the LSR MUST reserve the | |||
corresponding resources for the CR-LSP. | corresponding resources for the CR-LSP. | |||
If, after possible Traffic Parameter negotiation, an LSR cannot | If, after possible Traffic Parameter negotiation, an LSR cannot | |||
support the CR-LSP Traffic Parameters then the LSR MUST send a | support the CR-LSP Traffic Parameters then the LSR MUST send a | |||
Notification Message that contains the _Resource Unavailable_ status | Notification Message that contains the "Resource Unavailableö status | |||
code. | code. | |||
4.3.2.2 Label Mapping Message | 4.3.2.2 Label Mapping Message | |||
If an LSR receives an incorrectly encoded Traffic Parameters TLV in | If an LSR receives an incorrectly encoded Traffic Parameters TLV in | |||
which the value of PDR is less than the value of CDR then it MUST | which the value of PDR is less than the value of CDR then it MUST | |||
send a Label Release message containing the Status code _Traffic | send a Label Release message containing the Status code "Traffic | |||
Parameters Unavailable_ to the LSR from which it received the | Parameters Unavailableö to the LSR from which it received the | |||
erroneous message. In addition, the LSP should send a Notification | erroneous message. In addition, the LSP should send a Notification | |||
Message upstream with the status code _Label Request Aborted_. | Message upstream with the status code "Label Request Abortedö. | |||
If the negotiation flag was set in the label request message, the | If the negotiation flag was set in the label request message, the | |||
egress LSR MUST include the (possibly negotiated) Traffic Parameters | egress LSR MUST include the (possibly negotiated) Traffic Parameters | |||
and Weight in the Label Mapping message. | and Weight in the Label Mapping message. | |||
The Traffic Parameters and the Weight in a Label Mapping message | The Traffic Parameters and the Weight in a Label Mapping message | |||
MUST be forwarded unchanged. | MUST be forwarded unchanged. | |||
An LSR SHOULD adjust the resources that it reserved for a CR-LSP | An LSR SHOULD adjust the resources that it reserved for a CR-LSP | |||
when it receives a Label Mapping Message if the Traffic Parameters | when it receives a Label Mapping Message if the Traffic Parameters | |||
skipping to change at line 889 | skipping to change at line 869 | |||
the local LSR MUST propagate the Notification message using the | the local LSR MUST propagate the Notification message using the | |||
procedures in [1]. | procedures in [1]. | |||
4.4 Preemption TLV | 4.4 Preemption TLV | |||
The defualt value of the setup and holding priorities should be in | The defualt value of the setup and holding priorities should be in | |||
the middle of the range (e.g., 4) so that this feature can be turned | the middle of the range (e.g., 4) so that this feature can be turned | |||
on gradually in an operational network by increasing or decreasing | on gradually in an operational network by increasing or decreasing | |||
the priority starting at the middle of the range. | the priority starting at the middle of the range. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 17Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
Since the Preemption TLV is an optional TLV, LSPs that are setup | Since the Preemption TLV is an optional TLV, LSPs that are setup | |||
without an explicitly signaled preemption TLV SHOULD be treated as | without an explicitly signaled preemption TLV SHOULD be treated as | |||
LSPs with the default setup and holding priorities (e.g., 4). | LSPs with the default setup and holding priorities (e.g., 4). | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 17 | ||||
When an established LSP is preempted, the LSR that initiates the | When an established LSP is preempted, the LSR that initiates the | |||
preemption sends a Withdraw Message upstream and a Release Message | preemption sends a Withdraw Message upstream and a Release Message | |||
downstream. | downstream. | |||
When an LSP in the process of being established (outstanding Label | When an LSP in the process of being established (outstanding Label | |||
Request without getting a Label Mapping back) is preempted, the LSR | Request without getting a Label Mapping back) is preempted, the LSR | |||
that initiates the preemption, sends a Notification Message upstream | that initiates the preemption, sends a Notification Message upstream | |||
and an Abort Message downstream. | and an Abort Message downstream. | |||
0 1 2 3 | 0 1 2 3 | |||
skipping to change at line 944 | skipping to change at line 923 | |||
The higher the holding priority, the less likely it is for CR- | The higher the holding priority, the less likely it is for CR- | |||
LDP to reallocate its bandwidth to a new path. | LDP to reallocate its bandwidth to a new path. | |||
4.5 LSPID TLV | 4.5 LSPID TLV | |||
LSPID is a unique identifier of a CR-LSP within an MPLS network. | LSPID is a unique identifier of a CR-LSP within an MPLS network. | |||
The LSPID is composed of the ingress LSR Router ID (or any of its | The LSPID is composed of the ingress LSR Router ID (or any of its | |||
own Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR. | own Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 18Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
The LSPID is useful in network management, in CR-LSP repair, and in | The LSPID is useful in network management, in CR-LSP repair, and in | |||
using an already established CR-LSP as a hop in an ER-TLV. | using an already established CR-LSP as a hop in an ER-TLV. | |||
An _action indicator flag_ is carried in the LSPID TLV. This _action | Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 18 | |||
indicator flag_ indicates explicitly the action that should be taken | An "action indicator flagö is carried in the LSPID TLV. This "action | |||
indicator flagö indicates explicitly the action that should be taken | ||||
if the LSP already exists on the LSR receiving the message. | if the LSP already exists on the LSR receiving the message. | |||
After a CR-LSP is set up, its bandwidth reservation may need to be | After a CR-LSP is set up, its bandwidth reservation may need to be | |||
changed by the network operator, due to the new requirements for the | changed by the network operator, due to the new requirements for the | |||
traffic carried on that CR-LSP. The _action indicator flag_ is used | traffic carried on that CR-LSP. The "action indicator flagö is used | |||
indicate the need to modify the bandwidth and possibly other | indicate the need to modify the bandwidth and possibly other | |||
parameters of an established CR-LSP without service interruption. | parameters of an established CR-LSP without service interruption. | |||
This feature has application in dynamic network resources management | This feature has application in dynamic network resources management | |||
where traffic of different priorities and service classes is | where traffic of different priorities and service classes is | |||
involved. | involved. | |||
The procedure for the code point _modify_ is defined in [9]. The | The procedure for the code point "modifyö is defined in [8]. The | |||
procedures for other flags are FFS. | procedures for other flags are FFS. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0|0| Type = 0x0821 | Length = 4 | | |0|0| Type = 0x0821 | Length = 4 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Reserved |ActFlg | Local CR-LSP ID | | | Reserved |ActFlg | Local CR-LSP ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Ingress LSR Router ID | | | Ingress LSR Router ID | | |||
skipping to change at line 997 | skipping to change at line 975 | |||
0000: indicates initial LSP setup | 0000: indicates initial LSP setup | |||
0001: indicates modify LSP | 0001: indicates modify LSP | |||
Reserved | Reserved | |||
Zero on transmission. Ignored on receipt. | Zero on transmission. Ignored on receipt. | |||
Local CR-LSP ID | Local CR-LSP ID | |||
The Local LSP ID is an identifier of the CR-LSP locally unique | The Local LSP ID is an identifier of the CR-LSP locally unique | |||
within the Ingress LSR originating the CR-LSP. | within the Ingress LSR originating the CR-LSP. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 19Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
Ingress LSR Router ID | Ingress LSR Router ID | |||
An LSR may use any of its own IPv4 addresses in this field. | An LSR may use any of its own IPv4 addresses in this field. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 19 | ||||
4.6 Resource Class (Color) TLV | 4.6 Resource Class (Color) TLV | |||
The Resource Class as defined in [4] is used to specify which links | The Resource Class as defined in [3] is used to specify which links | |||
are acceptable by this CR-LSP. This information allows for the | are acceptable by this CR-LSP. This information allows for the | |||
network's topology to be pruned. | networkÆs topology to be pruned. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0|0| Type = 0x0822 | Length = 4 | | |0|0| Type = 0x0822 | Length = 4 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| RsCls | | | RsCls | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Type | Type | |||
A fourteen-bit field carrying the value of the ResCls-TLV Type | A fourteen-bit field carrying the value of the ResCls-TLV Type | |||
= 0x0822. | = 0x0822. | |||
Length | Length | |||
Specifies the length of the value field in bytes = 4. | Specifies the length of the value field in bytes = 4. | |||
RsCls | RsCls | |||
The Resource Class bit mask indicating which of the 32 | The Resource Class bit mask indicating which of the 32 | |||
_administrative groups_ or _colors_ of links the CR-LSP can | "administrative groupsö or "colorsö of links the CR-LSP can | |||
traverse. | traverse. | |||
4.7 ER-Hop semantics | 4.7 ER-Hop semantics | |||
4.7.1. ER-Hop 1: The IPv4 prefix | 4.7.1. ER-Hop 1: The IPv4 prefix | |||
The abstract node represented by this ER-Hop is the set of nodes, | The abstract node represented by this ER-Hop is the set of nodes, | |||
which have an IP address, which lies within this prefix. Note that | which have an IP address, which lies within this prefix. Note that | |||
a prefix length of 32 indicates a single IPv4 node. | a prefix length of 32 indicates a single IPv4 node. | |||
skipping to change at line 1051 | skipping to change at line 1029 | |||
|L| Reserved | PreLen | | |L| Reserved | PreLen | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IPv4 Address (4 bytes) | | | IPv4 Address (4 bytes) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Type | Type | |||
A fourteen-bit field carrying the value of the ER-Hop 1, IPv4 | A fourteen-bit field carrying the value of the ER-Hop 1, IPv4 | |||
Address, Type = 0x0801 | Address, Type = 0x0801 | |||
Length | Length | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 20Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
Specifies the length of the value field in bytes = 8. | Specifies the length of the value field in bytes = 8. | |||
L Bit | L Bit | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 20 | ||||
Set to indicate Loose hop. | Set to indicate Loose hop. | |||
Cleared to indicate a strict hop. | Cleared to indicate a strict hop. | |||
Reserved | Reserved | |||
Zero on transmission. Ignored on receipt. | Zero on transmission. Ignored on receipt. | |||
PreLen | PreLen | |||
Prefix Length 1-32 | Prefix Length 1-32 | |||
IP Address | IP Address | |||
skipping to change at line 1107 | skipping to change at line 1084 | |||
Reserved | Reserved | |||
Zero on transmission. Ignored on receipt. | Zero on transmission. Ignored on receipt. | |||
PreLen | PreLen | |||
Prefix Length 1-128 | Prefix Length 1-128 | |||
IPv6 address | IPv6 address | |||
A 128-bit unicast host address. | A 128-bit unicast host address. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 21Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
4.7.3. ER-Hop 3: The autonomous system number | 4.7.3. ER-Hop 3: The autonomous system number | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 21 | ||||
The abstract node represented by this ER-Hop is the set of nodes | The abstract node represented by this ER-Hop is the set of nodes | |||
belonging to the autonomous system. | belonging to the autonomous system. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|0|0| 0x0803 | Length = 4 | | |0|0| 0x0803 | Length = 4 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L| Reserved | AS Number | | |L| Reserved | AS Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at line 1160 | skipping to change at line 1136 | |||
the next ER-Hop after the loosely specified CR-LSP segment. Use of | the next ER-Hop after the loosely specified CR-LSP segment. Use of | |||
the LSPID Hop in this scenario eliminates the need for ER-Hops to | the LSPID Hop in this scenario eliminates the need for ER-Hops to | |||
keep the entire remaining ER-TLV at each LSR that is at either | keep the entire remaining ER-TLV at each LSR that is at either | |||
(upstream or downstream) end of a loosely specified CR-LSP segment | (upstream or downstream) end of a loosely specified CR-LSP segment | |||
as part of its state information. This is due to the fact that the | as part of its state information. This is due to the fact that the | |||
upstream LSR needs only to keep the next ER-Hop and the LSPID and | upstream LSR needs only to keep the next ER-Hop and the LSPID and | |||
the downstream LSR needs only to keep the LSPID in order for each | the downstream LSR needs only to keep the LSPID in order for each | |||
end to be able to recognize that the same LSP is being identified. | end to be able to recognize that the same LSP is being identified. | |||
If the LSPID Hop is not the last hop in an ER-TLV, the LSR must | If the LSPID Hop is not the last hop in an ER-TLV, the LSR must | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 22Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
remove the LSP-ID Hop and forward the remaining ER-TLV in a Label | remove the LSP-ID Hop and forward the remaining ER-TLV in a Label | |||
Request message using an LDP session established with the LSR that | Request message using an LDP session established with the LSR that | |||
is the specified CR-LSP's egress. That LSR will continue processing | is the specified CR-LSP's egress. That LSR will continue processing | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 22 | ||||
of the CR-LSP Label Request Message. The result is a tunneled, or | of the CR-LSP Label Request Message. The result is a tunneled, or | |||
stacked, CR-LSP. | stacked, CR-LSP. | |||
To support labels negotiated for tunneled CR-LSP segments, an LDP | To support labels negotiated for tunneled CR-LSP segments, an LDP | |||
session is required [1] between tunnel end points - possibly using | session is required [1] between tunnel end points - possibly using | |||
the existing CR-LSP. Use of the existence of the CR-LSP in lieu of | the existing CR-LSP. Use of the existence of the CR-LSP in lieu of | |||
a session, or other possible session-less approaches, is FFS. | a session, or other possible session-less approaches, is FFS. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
skipping to change at line 1214 | skipping to change at line 1189 | |||
4.8. Processing of the Explicit Route TLV | 4.8. Processing of the Explicit Route TLV | |||
4.8.1. Selection of the next hop | 4.8.1. Selection of the next hop | |||
A Label Request Message containing an explicit route TLV must | A Label Request Message containing an explicit route TLV must | |||
determine the next hop for this path. Selection of this next hop | determine the next hop for this path. Selection of this next hop | |||
may involve a selection from a set of possible alternatives. The | may involve a selection from a set of possible alternatives. The | |||
mechanism for making a selection from this set is implementation | mechanism for making a selection from this set is implementation | |||
dependent and is outside of the scope of this specification. | dependent and is outside of the scope of this specification. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 23Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
Selection of particular paths is also outside of the scope of this | Selection of particular paths is also outside of the scope of this | |||
specification, but it is assumed that each node will make a best | specification, but it is assumed that each node will make a best | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 23 | ||||
effort attempt to determine a loop-free path. Note that such best | effort attempt to determine a loop-free path. Note that such best | |||
efforts may be overridden by local policy. | efforts may be overridden by local policy. | |||
To determine the next hop for the path, a node performs the | To determine the next hop for the path, a node performs the | |||
following steps: | following steps: | |||
1. The node receiving the Label Request Message must first | 1. The node receiving the Label Request Message must first | |||
evaluate the first ER-Hop. If the L bit is not set in the | evaluate the first ER-Hop. If the L bit is not set in the first | |||
first ER-Hop and if the node is not part of the abstract node | ER-Hop and if the node is not part of the abstract node described | |||
described by the first ER-Hop, it has received the message in | by the first ER-Hop, it has received the message in error, and | |||
error, and should return a _Bad Initial ER-Hop_ error. If the | should return a "Bad Initial ER-Hopö error. If the L bit is set | |||
L bit is set and the local node is not part of the abstract | and the local node is not part of the abstract node described by | |||
node described by the first ER-Hop, the node selects a next | the first ER-Hop, the node selects a next hop that is along the | |||
hop that is along the path to the abstract node described by | path to the abstract node described by the first ER-Hop. If there | |||
the first ER-Hop. If there is no first ER-Hop, the message is | is no first ER-Hop, the message is also in error and the system | |||
also in error and the system should return a _Bad Explicit | should return a "Bad Explicit Routing TLVö error using a | |||
Routing TLV_ error using a Notification Message sent upstream. | Notification Message sent upstream. | |||
2. If there is no second ER-Hop, this indicates the end of the | 2. If there is no second ER-Hop, this indicates the end of the | |||
explicit route. The explicit route TLV should be removed from | explicit route. The explicit route TLV should be removed from the | |||
the Label Request Message. This node may or may not be the | Label Request Message. This node may or may not be the end of | |||
end of the LSP. Processing continues with section 4.8.2, | the LSP. Processing continues with section 4.8.2, where a new | |||
where a new explicit route TLV may be added to the Label | explicit route TLV may be added to the Label Request Message. | |||
Request Message. | ||||
3. If the node is also a part of the abstract node described by | 3. If the node is also a part of the abstract node described by | |||
the second ER-Hop, then the node deletes the first ER-Hop and | the second ER-Hop, then the node deletes the first ER-Hop and | |||
continues processing with step 2, above. Note that this makes | continues processing with step 2, above. Note that this makes | |||
the second ER-Hop into the first ER-Hop of the next iteration. | the second ER-Hop into the first ER-Hop of the next iteration. | |||
4. The node determines if it is topologically adjacent to the | 4. The node determines if it is topologically adjacent to the | |||
abstract node described by the second ER-Hop. If so, the node | abstract node described by the second ER-Hop. If so, the node | |||
selects a particular next hop which is a member of the | selects a particular next hop which is a member of the abstract | |||
abstract node. The node then deletes the first ER-Hop and | node. The node then deletes the first ER-Hop and continues | |||
continues processing with section 4.8.2. | processing with section 4.8.2. | |||
5. Next, the node selects a next hop within the abstract node of | 5. Next, the node selects a next hop within the abstract node of | |||
the first ER-Hop that is along the path to the abstract node | the first ER-Hop that is along the path to the abstract node of | |||
of the second ER-Hop. If no such path exists then there are | the second ER-Hop. If no such path exists then there are two | |||
two cases: | cases: | |||
5.a If the second ER-Hop is a strict ER-Hop, then there is | 5.a If the second ER-Hop is a strict ER-Hop, then there is | |||
an error and the node should return a _Bad Strict Node_ | an error and the node should return a "Bad Strict Nodeö | |||
error. | error. | |||
5.b Otherwise, if the second ER-Hop is a loose ER-Hop, then | 5.b Otherwise, if the second ER-Hop is a loose ER-Hop, then | |||
the node selects any next hop that is along the path to the | the node selects any next hop that is along the path to the | |||
next abstract node. If no path exists within the MPLS | next abstract node. If no path exists within the MPLS | |||
domain, then there is an error, and the node should return a | domain, then there is an error, and the node should return a | |||
_Bad loose node_ error. | "Bad loose nodeö error. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 24Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
6. Finally, the node replaces the first ER-Hop with any ER-Hop | 6. Finally, the node replaces the first ER-Hop with any ER-Hop | |||
that denotes an abstract node containing the next hop. This | that denotes an abstract node containing the next hop. This is | |||
is necessary so that when the explicit route is received by | ||||
the next hop, it will be accepted. | Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 24 | |||
necessary so that when the explicit route is received by the next | ||||
hop, it will be accepted. | ||||
7. Progress the Label Request Message to the next hop. | 7. Progress the Label Request Message to the next hop. | |||
4.8.2. Adding ER-Hops to the explicit route TLV | 4.8.2. Adding ER-Hops to the explicit route TLV | |||
After selecting a next hop, the node may alter the explicit route in | After selecting a next hop, the node may alter the explicit route in | |||
the following ways. | the following ways. | |||
If, as part of executing the algorithm in section 4.8.1, the | If, as part of executing the algorithm in section 4.8.1, the | |||
explicit route TLV is removed, the node may add a new explicit route | explicit route TLV is removed, the node may add a new explicit route | |||
skipping to change at line 1323 | skipping to change at line 1296 | |||
Length | Length | |||
Specifies the length of the value field in bytes = 4. | Specifies the length of the value field in bytes = 4. | |||
P Bit | P Bit | |||
The P bit is set to 1 to indicate that route pinning is | The P bit is set to 1 to indicate that route pinning is | |||
requested. | requested. | |||
The P bit is set to 0 to indicate that route pinning is not | The P bit is set to 0 to indicate that route pinning is not | |||
requested | requested | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 25Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
Reserved | Reserved | |||
Zero on transmission. Ignored on receipt. | Zero on transmission. Ignored on receipt. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 25 | ||||
4.10 CR-LSP FEC Element | 4.10 CR-LSP FEC Element | |||
A new FEC element is introduced in this specification to support CR- | A new FEC element is introduced in this specification to support CR- | |||
LSPs. A FEC TLV containing a FEC of Element type CR-LSP (0x04) is a | LSPs. A FEC TLV containing a FEC of Element type CR-LSP (0x04) is a | |||
CR-LSP FEC TLV. The CR-LSP FEC Element is an opaque FEC to be used | CR-LSP FEC TLV. The CR-LSP FEC Element is an opaque FEC to be used | |||
only in Messages of CR-LSPs. | only in Messages of CR-LSPs. | |||
A single FEC element MUST be included in the Label Request Message. | A single FEC element MUST be included in the Label Request Message. | |||
The FEC Element SHOULD be the CR-LSP FEC Element. However, one of | The FEC Element SHOULD be the CR-LSP FEC Element. However, one of | |||
the other FEC elements (Type=0x01, 0x02, 0x03) defined in [1] MAY be | the other FEC elements (Type=0x01, 0x02, 0x03) defined in [1] MAY be | |||
skipping to change at line 1365 | skipping to change at line 1338 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
Type | Type | |||
A fourteen-bit field carrying the value of the FEC TLV | A fourteen-bit field carrying the value of the FEC TLV | |||
Type = 0x0100 | Type = 0x0100 | |||
Length | Length | |||
Specifies the length of the value field in bytes = 1. | Specifies the length of the value field in bytes = 1. | |||
CR-LSP FEC Element Type | CR-LSP FEC Element Type | |||
0x04 | 0x04 | |||
4.11 TLV Type Summary | 5. IANA Considerations | |||
CR-LDP defines the following name spaces, which require management: | ||||
- TLV types. | ||||
- FEC types. | ||||
- Status codes. | ||||
The following sections provide guidelines for managing these name | ||||
spaces. | ||||
5.1 TLV Type Name Space | ||||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 26 | ||||
RFC 3036 [1] defines the LDP TLV name space. This document further | ||||
subdivides the range of RFC 3036 from that TLV space for TLVs | ||||
associated with the CR-LDP in the range 0x0800 - 0x08FF. | ||||
Following the policies outlined in [IANA], TLV types in this range | ||||
are allocated through an IETF Consensus action. | ||||
Initial values for this range are specified in the following table: | ||||
TLV Type | TLV Type | |||
-------------------------------------- ---------- | -------------------------------------- ---------- | |||
Explicit Route TLV 0x0800 | Explicite Route TLV 0x0800 | |||
Ipv4 Prefix ER-Hop TLV 0x0801 | Ipv4 Prefix ER-Hop TLV 0x0801 | |||
Ipv6 Prefix ER-Hop TLV 0x0802 | Ipv6 Prefix ER-Hop TLV 0x0802 | |||
Autonomous System Number ER-Hop TLV 0x0803 | Autonomous System Number ER-Hop TLV 0x0803 | |||
LSP-ID ER-Hop TLV 0x0804 | LSP-ID ER-Hop TLV 0x0804 | |||
Traffic Parameters TLV 0x0810 | Traffic Parameters TLV 0x0810 | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 26Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
Preemption TLV 0x0820 | Preemption TLV 0x0820 | |||
LSPID TLV 0x0821 | LSPID TLV 0x0821 | |||
Resource Class TLV 0x0822 | Resource Class TLV 0x0822 | |||
Route Pinning TLV 0x0823 | Route Pinning TLV 0x0823 | |||
4.12 FEC Type Summary | 5.2 FEC Type Name Space | |||
RFC 3036 defines the FEC Type TLV name space. This document further | ||||
subdivides the range of RFC 3036 from that TLV space for TLVs | ||||
associated with the CR-LDP in the range 100 - 116. | ||||
Following the policies outlined in [IANA], TLV types in this range | ||||
are allocated through an IETF Consensus action. | ||||
Initial values for this range are specified in the follwing table: | ||||
FEC Element TLV Type | FEC Element TLV Type | |||
-------------------------------------- ---------- | -------------------------------------- ---------- | |||
CR-LSP FEC Element TLV 0x0100 | CR-LSP FEC Element TLV 0x0100 | |||
4.13 Status Code Summary | 5.3 Status Code Space | |||
RFC 3036 defines the Status Code name space. This document further | ||||
subdivides the range of RFC 3036 from that TLV space for TLVs | ||||
associated with the CR-LDP in the range 0x44000000 - 0x440000FF. | ||||
Following the policies outlined in [IANA], TLV types in this range | ||||
are allocated through an IETF Consensus action. | ||||
Initial values for this range are specified in the follwing table: | ||||
Status Code Type | Status Code Type | |||
-------------------------------------- ---------- | -------------------------------------- ---------- | |||
Bad Explicit Routing TLV Error 0x44000001 | Bad Explicit Routing TLV Error 0x44000001 | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 27 | ||||
Bad Strict Node Error 0x44000002 | Bad Strict Node Error 0x44000002 | |||
Bad Loose Node Error 0x44000003 | Bad Loose Node Error 0x44000003 | |||
Bad Initial ER-Hop Error 0x44000004 | Bad Initial ER-Hop Error 0x44000004 | |||
Resource Unavailable 0x44000005 | Resource Unavailable 0x44000005 | |||
Traffic Parameters Unavailable 0x44000006 | Traffic Parameters Unavailable 0x44000006 | |||
LSP Preempted 0x44000007 | LSP Preempted 0x44000007 | |||
Modify Request Not Supported 0x44000008 | Modify Request Not Supported 0x44000008 | |||
Setup Abort (Label Request Aborted in [1]) 0x04000015 | Setup Abort (Label Request Aborted in [1]) 0x04000015 | |||
5. IANA Considerations | ||||
CR-LDP defines the following name spaces, which require management: | ||||
- TLV types. | ||||
- FEC types. | ||||
- Status codes. | ||||
The following sections provide guidelines for managing these name | ||||
spaces. | ||||
5.1 TLV Type Name Space | ||||
TLV types in the range 0x0800 - 0x08FF are allocated to CR-LDP base | ||||
protocol. Following the policies outlined in [IANA], TLV types in | ||||
this range are allocated through an IETF Consensus action. | ||||
5.2 FEC Type Name Space | ||||
FEC Type 100 is allocated to CR-LDP. | ||||
5.3 Status Code Space | ||||
The range for Status Codes is 0x44000000 - 0x440000FF. | ||||
Following the policies outlined in [IANA], Status Codes in the range | ||||
0x44000000 - 0x440000FF are allocated through an IETF Consensus | ||||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 27Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | ||||
action. | ||||
6. Security | 6. Security | |||
CR-LDP inherits the same security mechanism described in Section 4.0 | CR-LDP inherits the same security mechanism described in Section 4.0 | |||
of [1] to protect against the introduction of spoofed TCP segments | of [1] to protect against the introduction of spoofed TCP segments | |||
into LDP session connection streams. | into LDP session connection streams. | |||
7. Acknowledgments | 7. Acknowledgments | |||
The messages used to signal the CR-LSP setup are based on the work | The messages used to signal the CR-LSP setup are based on the work | |||
done by the [1] team. | done by the [1] team. | |||
skipping to change at line 1461 | skipping to change at line 1441 | |||
8. Intellectual Property Consideration | 8. Intellectual Property Consideration | |||
The IETF has been notified of intellectual property rights claimed | The IETF has been notified of intellectual property rights claimed | |||
in regard to some or all of the specification contained in this | in regard to some or all of the specification contained in this | |||
document. For more information consult the online list of claimed | document. For more information consult the online list of claimed | |||
rights. | rights. | |||
9. References | 9. References | |||
1 Andersson et al, "Label Distribution Protocol Specification" | 1 Andersson et. al., "Label Distribution Protocol Specification" | |||
work in progress (draft-ietf-mpls-ldp-08), June 2000. | RFC 3036, January 2001. | |||
2 Callon et al, "Framework for Multiprotocol Label Switching", | ||||
work in progress (draft-ietf-mpls-framework-05), September 1999. | ||||
3 Rosen et al, "Multiprotocol Label Switching Architecture", | 2 Rosen et. al., "Multiprotocol Label Switching Architecture", | |||
work in progress (draft-ietf-mpls-arch-06), August 1999. | RFC 3031, January 2001. | |||
4 Awduche et al, "Requirements for Traffic Engineering Over | 3 Awduche et. al., "Requirements for Traffic Engineering Over | |||
MPLS", RFC 2702, September 1999. | MPLS", RFC 2702, September 1999. | |||
5 B. Gleeson, et. al., "A Framework for IP Based Virtual Private | 4 Gleeson, et. al., "A Framework for IP Based Virtual Private | |||
Networks", RFC 2764, February 2000. | Networks", RFC 2764, February 2000. | |||
6 B. Jamoussi, et. al., _Applicability Statement for CR-LDP_, work | 5 B. Jamoussi, et. al., ôApplicability Statement for CR-LDPö, work | |||
in progress, (draft-ietf-mpls-crldp-applic-01), June 2000. | in progress, (draft-ietf-mpls-crldp-applic-01), June 2000. | |||
7 S. Bradner, "Key words for use in RFCs to Indicate Requirement | 6 S. Bradner, "Key words for use in RFCs to Indicate Requirement | |||
Levels_, RFC 2119, March 1997. | Levelsö, RFC 2119, March 1997. | |||
8 L. Wu, et. al., "LDP State Machine", work in progress, | Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 28 | |||
7 L. Wu, et. al., "LDP State Machine", work in progress, | ||||
(draft-ietf-mpls-ldp-state-03), January 2000. | (draft-ietf-mpls-ldp-state-03), January 2000. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 28Internet Draft Constraint-Based LSP Setup using LDP July, 2000 | 8 J. Ash, et. al., "LSP Modification Using CR-LDP", work in | |||
progress, (draft-ietf-mpls-crlsp-modify-02), October 2000. | ||||
9 J. Ash, et. al., "LSP Modification Using CR-LDP", work in | ||||
progress, (draft-ietf-mpls-crlsp-modify-01), February 2000. | ||||
10. Author's Addresses | 10. AuthorÆs Addresses | |||
Osama S. Aboul-Magd Loa Andersson | Osama S. Aboul-Magd Loa Andersson | |||
Nortel Networks Nortel Networks | Nortel Networks Nortel Networks | |||
P O Box 3511 Station C S:t Eriksgatan 115 | P O Box 3511 Station C S:t Eriksgatan 115 | |||
Ottawa, ON K1Y 4H7 PO Box 6701 | Ottawa, ON K1Y 4H7 PO Box 6701 | |||
Canada 113 85 Stockholm | Canada 113 85 Stockholm | |||
Phone: +1 613 763-5827 Tel: +46 8 508 835 00 | Phone: +1 613 763-5827 Tel: +46 8 508 835 00 | |||
Osama@nortelnetworks.com Fax: +46 8 508 835 01 | Osama@nortelnetworks.com Fax: +46 8 508 835 01 | |||
Loa_andersson@nortelnetworks.com | Loa_andersson@nortelnetworks.com | |||
Peter Ashwood-Smith Ross Callon | Peter Ashwood-Smith Ross Callon | |||
Nortel Networks Juniper Networks | Nortel Networks Juniper Networks | |||
P O Box 3511 Station C 1194 North Mathilda Avenue, | P O Box 3511 Station C 1194 North Mathilda Avenue, | |||
Ottawa, ON K1Y 4H7 Sunnyvale, CA 94089 | Ottawa, ON K1Y 4H7 Sunnyvale, CA 94089 | |||
Canada 978-692-6724 | Canada 978-692-6724 | |||
Phone: +1 613 763-4534 rcallon@juniper.net | Phone: +1 613 763-4534 rcallon@juniper.net | |||
Petera@nortelnetworks.com | Petera@nortelnetworks.com | |||
Ram Dantu Paul Doolan | Ram Dantu Paul Doolan | |||
IPmobile Ennovate Networks | Cisco Systems Ennovate Networks | |||
1651 North Glenville, Suite 216 330 Codman Hill Rd | 17919 Waterview Parkway 330 Codman Hill Rd | |||
Richardson, TX 75081 Marlborough MA 01719 | Dallas, 75252 Marlborough MA 01719 | |||
+1-972-234-6070 extension 211 Phone: 978-263-2002 | +1 469 255 0716 Phone: 978-263-2002 | |||
rdantu@ipmobile.com Pdoolan@ennovatenetworks.com | rdantu@cisco.com Pdoolan@ennovatenetworks.com | |||
Nancy Feldman Andre Fredette | Nancy Feldman Andre Fredette | |||
IBM Corp. PhotonEx Corporation | IBM Research PhotonEx Corporation | |||
17 Skyline Drive 135 South Road | 30 Saw Mill River Road 135 South Road | |||
Hawthorne NY 10532 Bedford, MA 01730 | Hawthorne, NY 10532 Bedford, MA 01730 | |||
Phone: 914-784-3254 email: fredette@photonex.com | Phone: 914-784-3254 email: fredette@photonex.com | |||
Nkf@us.ibm.com phone: 781-275-8500 | Nkf@us.ibm.com phone: 781-275-8500 | |||
Eric Gray Joel M. Halpern | Eric Gray Joel M. Halpern | |||
Zaffire, Inc Longitude Systems, Inc. | 600 Federal Drive Longitude Systems, Inc. | |||
2630 Orchard Parkway, 1319 Shepard Road | Andover, MA 01810 1319 Shepard Road | |||
San Jose, CA 95134-2020 Sterling, VA 20164 | Phone: (978) 689-1610 Sterling, VA 20164 | |||
Phone: 408-894-7362 703-433-0808 x207 | eric.gray@sandburst.com 703-433-0808 x207 | |||
egray@zaffire.com joel@longsys.com | joel@longsys.com | |||
Juha Heinanen Fiffi Hellstrand | Juha Heinanen Fiffi Hellstrand | |||
Telia Finland, Inc. Nortel Networks | Telia Finland, Inc. Nortel Networks | |||
Myyrmaentie 2 S:t Eriksgatan 115 | Myyrmaentie 2 S:t Eriksgatan 115 | |||
01600 VANTAA PO Box 6701, 113 85 Stockholm | 01600 VANTAA PO Box 6701, 113 85 Stockholm | |||
Finland Sweden | Finland Sweden | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-05.txt 29 | ||||
Tel: +358 41 500 4808 +46705593687 | Tel: +358 41 500 4808 +46705593687 | |||
Jh@telia.fi fiffi@nortelnetworks.com | Jh@telia.fi fiffi@nortelnetworks.com | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-04.txt 29Internet Draft Constraint-Based LSP Setup using LDP July 2000 | ||||
Bilel Jamoussi Timothy E. Kilty | Bilel Jamoussi Timothy E. Kilty | |||
Nortel Networks Corp. Newbridge Networks, Inc. | Nortel Networks Corp. Newbridge Networks, Inc. | |||
600 Technology Park Drive 5 Corporate Drive | 600 Technology Park Drive 5 Corporate Drive | |||
Billerica, MA 01821 Andover, MA 01810 | Billerica, MA 01821 Andover, MA 01810 | |||
USA USA | USA USA | |||
Phone: +1 978 288-4506 phone: 978 691-4656 | Phone: +1 978 288-4506 phone: 978 691-4656 | |||
Jamoussi@nortelnetworks.com tkilty@northchurch.net | Jamoussi@nortelnetworks.com tkilty@northchurch.net | |||
Andrew G. Malis Muckai K Girish | Andrew G. Malis Muckai K Girish | |||
Vivace Networks Atoga Systems | Vivace Networks Atoga Systems | |||
skipping to change at line 1572 | skipping to change at line 1548 | |||
Fax: +46 8 508 835 01 | Fax: +46 8 508 835 01 | |||
Ksundell@nortelnetworks.com | Ksundell@nortelnetworks.com | |||
Tom Worster Liwen Wu | Tom Worster Liwen Wu | |||
Ennovate Networks Cisco Systems | Ennovate Networks Cisco Systems | |||
60 Codman Hill Rd 250 Apollo Drive | 60 Codman Hill Rd 250 Apollo Drive | |||
Boxborough Chelmsford, MA. 01824 | Boxborough Chelmsford, MA. 01824 | |||
MA 01719 Tel: 978-244-3087. | MA 01719 Tel: 978-244-3087. | |||
tworster@ennovatenetworks.com liwwu@cisco.com | tworster@ennovatenetworks.com liwwu@cisco.com | |||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 30Internet Draft Constraint-Based LSP Setup using LDP July 2000 | Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 30 | |||
Appendix A: CR-LSP Establishment Examples | Appendix A: CR-LSP Establishment Examples | |||
A.1 Strict Explicit Route Example | A.1 Strict Explicit Route Example | |||
This appendix provides an example for the setup of a strictly routed | This appendix provides an example for the setup of a strictly routed | |||
CR-LSP. In this example, a specific node represents each abstract | CR-LSP. In this example, a specific node represents each abstract | |||
node. | node. | |||
The sample network used here is a four node network with two edge | The sample network used here is a four node network with two edge | |||
skipping to change at line 1599 | skipping to change at line 1575 | |||
of this draft and sends it to LSR2. This message includes the CR- | of this draft and sends it to LSR2. This message includes the CR- | |||
TLV. | TLV. | |||
A vector of three ER-Hop TLVs <a, b, c> composes the ER-TLV. | A vector of three ER-Hop TLVs <a, b, c> composes the ER-TLV. | |||
The ER-Hop TLVs used in this example are of type 0x0801 (IPv4 | The ER-Hop TLVs used in this example are of type 0x0801 (IPv4 | |||
prefix) with a prefix length of 32. Hence, each ER-Hop TLV | prefix) with a prefix length of 32. Hence, each ER-Hop TLV | |||
identifies a specific node as opposed to a group of nodes. | identifies a specific node as opposed to a group of nodes. | |||
At LSR2, the following processing of the ER-TLV per Section 4.8.1 of | At LSR2, the following processing of the ER-TLV per Section 4.8.1 of | |||
this draft takes place: | this draft takes place: | |||
1) The node LSR2 is part of the abstract node described by the | 1. The node LSR2 is part of the abstract node described by the | |||
first hop <a>. Therefore, the first step passes the test. | first hop <a>. Therefore, the first step passes the test. Go | |||
Go to step 2. | to step 2. | |||
2) There is a second ER-Hop, <b>. Go to step 3. | 2. There is a second ER-Hop, <b>. Go to step 3. | |||
3) LSR2 is not part of the abstract node described by the | 3. LSR2 is not part of the abstract node described by the | |||
second ER-Hop <b>. Go to Step 4. | second ER-Hop <b>. Go to Step 4. | |||
4) LSR2 determines that it is topologically adjacent to the | 4. LSR2 determines that it is topologically adjacent to the | |||
abstract node described by the second ER-Hop <b>. LSR2 | abstract node described by the second ER-Hop <b>. LSR2 selects | |||
selects a next hop (LSR3) which is the abstract node. LSR2 | a next hop (LSR3) which is the abstract node. LSR2 deletes the | |||
deletes the first ER-Hop <a> from the ER-TLV, which now | first ER-Hop <a> from the ER-TLV, which now becomes <b, c>. | |||
becomes <b, c>. Processing continues with Section 4.8.2. | Processing continues with Section 4.8.2. | |||
At LSR2, the following processing of Section 4.8.2 takes place: | At LSR2, the following processing of Section 4.8.2 takes place: | |||
Executing algorithm 4.8.1 did not result in the removal of the ER- | Executing algorithm 4.8.1 did not result in the removal of the ER- | |||
TLV. | TLV. | |||
Also, LSR2 is not a member of the abstract node described by the | Also, LSR2 is not a member of the abstract node described by the | |||
first ER-Hop <b>. | first ER-Hop <b>. | |||
Finally, the first ER-Hop <b> is a strict hop. | Finally, the first ER-Hop <b> is a strict hop. | |||
Therefore, processing section 4.8.2 does not result in the insertion | Therefore, processing section 4.8.2 does not result in the insertion | |||
of new ER-Hops. The selection of the next hop has been already done | of new ER-Hops. The selection of the next hop has been already done | |||
is step 4 of Section 4.8.1 and the processing of the ER-TLV is | is step 4 of Section 4.8.1 and the processing of the ER-TLV is | |||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 31Internet Draft Constraint-Based LSP Setup using LDP July 2000 | Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 31 | |||
completed at LSR2. In this case, the Label Request Message including | completed at LSR2. In this case, the Label Request Message including | |||
the ER-TLV <b, c> is progressed by LSR2 to LSR3. | the ER-TLV <b, c> is progressed by LSR2 to LSR3. | |||
At LSR3, a similar processing to the ER-TLV takes place except that | At LSR3, a similar processing to the ER-TLV takes place except that | |||
the incoming ER-TLV = <b, c> and the outgoing ER-TLV is <c>. | the incoming ER-TLV = <b, c> and the outgoing ER-TLV is <c>. | |||
At LSR4, the following processing of section 4.8.1 takes place: | At LSR4, the following processing of section 4.8.1 takes place: | |||
1) The node LSR4 is part of the abstract node described by the | 1. The node LSR4 is part of the abstract node described by the | |||
first hop <c>. Therefore, the first step passes the test. Go | first hop <c>. Therefore, the first step passes the test. Go to | |||
to step 2. | step 2. | |||
2) There is no second ER-Hop, this indicates the end of the CR- | ||||
2. There is no second ER-Hop, this indicates the end of the CR- | ||||
LSP. The ER-TLV is removed from the Label Request Message. | LSP. The ER-TLV is removed from the Label Request Message. | |||
Processing continues with Section 4.8.2. | Processing continues with Section 4.8.2. | |||
At LSR4, the following processing of Section 4.8.2 takes place: | At LSR4, the following processing of Section 4.8.2 takes place: | |||
Executing algorithm 4.8.1 resulted in the removal of the ER-TLV. | Executing algorithm 4.8.1 resulted in the removal of the ER-TLV. | |||
LSR4 does not add a new ER-TLV. | LSR4 does not add a new ER-TLV. | |||
Therefore, processing section 4.8.2 does not result in the insertion | Therefore, processing section 4.8.2 does not result in the insertion | |||
of new ER-Hops. This indicates the end of the CR-LSP and the | of new ER-Hops. This indicates the end of the CR-LSP and the | |||
processing of the ER-TLV is completed at LSR4. | processing of the ER-TLV is completed at LSR4. | |||
skipping to change at line 1680 | skipping to change at line 1656 | |||
management system or an application, the details are implementation | management system or an application, the details are implementation | |||
specific. | specific. | |||
The ingress LSR uses information provided by the management system | The ingress LSR uses information provided by the management system | |||
or the application and possibly also information from the routing | or the application and possibly also information from the routing | |||
database to calculate the explicit route and to create the Label | database to calculate the explicit route and to create the Label | |||
Request Message. | Request Message. | |||
The Label request message carries together with other necessary | The Label request message carries together with other necessary | |||
information an ER-TLV defining the explicitly routed path. In our | information an ER-TLV defining the explicitly routed path. In our | |||
example the list of hops in the ER-Hop TLV is supposed to contain an | ||||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 32Internet Draft Constraint-Based LSP Setup using LDP July 2000 | ||||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 32 | ||||
example the list of hops in the ER-Hop TLV is supposed to contain an | ||||
abstract node representing a group of nodes, an abstract node | abstract node representing a group of nodes, an abstract node | |||
representing a specific node, another abstract node representing a | representing a specific node, another abstract node representing a | |||
group of nodes, and an abstract node representing a specific egress | group of nodes, and an abstract node representing a specific egress | |||
point. | point. | |||
In--{Group 1}--{Specific A}--{Group 2}--{Specific Out: B} | In--{Group 1}--{Specific A}--{Group 2}--{Specific Out: B} | |||
The ER-TLV contains four ER-Hop TLVs: | The ER-TLV contains four ER-Hop TLVs: | |||
1. An ER-Hop TLV that specifies a group of LSR valid for the | 1. An ER-Hop TLV that specifies a group of LSR valid for the | |||
first abstract node representing a group of nodes (Group 1). | first abstract node representing a group of nodes (Group 1). | |||
2. An ER-Hop TLV that indicates the specific node (Node A). | 2. An ER-Hop TLV that indicates the specific node (Node A). | |||
3. An ER-Hop TLV that specifies a group of LSRs valid for the | 3. An ER-Hop TLV that specifies a group of LSRs valid for the | |||
second abstract node representing a group of nodes (Group | second abstract node representing a group of nodes (Group 2). | |||
2). | ||||
4. An ER-Hop TLV that indicates the specific egress point for | 4. An ER-Hop TLV that indicates the specific egress point for | |||
the CR-LSP (Node B). | the CR-LSP (Node B). | |||
All the ER-Hop TLVs are strictly routed nodes. | All the ER-Hop TLVs are strictly routed nodes. | |||
The setup procedure for this CR-LSP works as follows: | The setup procedure for this CR-LSP works as follows: | |||
1. The ingress node sends the Label Request Message to a node | 1. The ingress node sends the Label Request Message to a node | |||
that is a member the group of nodes indicated in the first | that is a member the group of nodes indicated in the first ER- | |||
ER-Hop TLV, following normal routing for the specific node | Hop TLV, following normal routing for the specific node (A). | |||
(A). | ||||
2. The node that receives the message identifies itself as part | 2. The node that receives the message identifies itself as part | |||
of the group indicated in the first ER-Hop TLV, and that it | of the group indicated in the first ER-Hop TLV, and that it is | |||
is not the specific node (A) in the second. Further it | not the specific node (A) in the second. Further it realizes | |||
realizes that the specific node (A) is not one of its next | that the specific node (A) is not one of its next hops. | |||
hops. | ||||
3. It keeps the ER-Hop TLVs intact and sends a Label Request | 3. It keeps the ER-Hop TLVs intact and sends a Label Request | |||
Message to another node that is part of the group indicated | Message to another node that is part of the group indicated in | |||
in the first ER-Hop TLV (Group 1), following normal routing | the first ER-Hop TLV (Group 1), following normal routing for | |||
for the specific node (A). | the specific node (A). | |||
4. The node that receives the message identifies itself as part | 4. The node that receives the message identifies itself as part | |||
of the group indicated in the first ER-Hop TLV, and that it | of the group indicated in the first ER-Hop TLV, and that it is | |||
is not the specific node (A) in the second ER-Hop TLV. | not the specific node (A) in the second ER-Hop TLV. Further it | |||
Further it realizes that the specific node (A) is one of its | realizes that the specific node (A) is one of its next hops. | |||
next hops. | ||||
5. It removes the first ER-Hop TLVs and sends a Label Request | 5. It removes the first ER-Hop TLVs and sends a Label Request | |||
Message to the specific node (A). | Message to the specific node (A). | |||
6. The specific node (A) recognizes itself in the first ER-Hop | 6. The specific node (A) recognizes itself in the first ER-Hop | |||
TLV. Removes the specific ER-Hop TLV. | TLV. Removes the specific ER-Hop TLV. | |||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 33Internet Draft Constraint-Based LSP Setup using LDP July 2000 | ||||
7. It sends a Label Request Message to a node that is a member | 7. It sends a Label Request Message to a node that is a member | |||
of the group (Group 2) indicated in the ER-Hop TLV. | of the group (Group 2) indicated in the ER-Hop TLV. | |||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 33 | ||||
8. The node that receives the message identifies itself as part | 8. The node that receives the message identifies itself as part | |||
of the group indicated in the first ER-Hop TLV, further it | of the group indicated in the first ER-Hop TLV, further it | |||
realizes that the specific egress node (B) is one of its | realizes that the specific egress node (B) is one of its next | |||
next hops. | hops. | |||
9. It sends a Label Request Message to the specific egress node | 9. It sends a Label Request Message to the specific egress node | |||
(B). | (B). | |||
10.The specific egress node (B) recognizes itself as the egress | 10. The specific egress node (B) recognizes itself as the | |||
for the CR-LSP, it returns a Label Mapping Message, that | egress for the CR-LSP, it returns a Label Mapping Message, that | |||
will traverse the same path as the Label Request Message in | will traverse the same path as the Label Request Message in the | |||
the opposite direction. | opposite direction. | |||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 34Internet Draft Constraint-Based LSP Setup using LDP July 2000 | ||||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 34 | ||||
Appendix B. QoS Service Examples | Appendix B. QoS Service Examples | |||
B.1 Service Examples | B.1 Service Examples | |||
Construction of an end-to-end service is the result of the rules | Construction of an end-to-end service is the result of the rules | |||
enforced at the edge and the treatment that packets receive at the | enforced at the edge and the treatment that packets receive at the | |||
network nodes. The rules define the traffic conditioning actions | network nodes. The rules define the traffic conditioning actions | |||
that are implemented at the edge and they include policing with | that are implemented at the edge and they include policing with | |||
pass, mark, and drop capabilities. The edge rules are expected tobe | pass, mark, and drop capabilities. The edge rules are expected tobe | |||
defined by the mutual agreements between the service providers and | defined by the mutual agreements between the service providers and | |||
skipping to change at line 1808 | skipping to change at line 1777 | |||
ATM-VBR.3(nrt) PCR CDVT SCR MBS 0 Unspecified drop>PCR | ATM-VBR.3(nrt) PCR CDVT SCR MBS 0 Unspecified drop>PCR | |||
mark>SCR,MBS | mark>SCR,MBS | |||
ATM-UBR PCR CDVT - - 0 Unspecified drop>PCR | ATM-UBR PCR CDVT - - 0 Unspecified drop>PCR | |||
ATM-GFR.1 PCR CDVT MCR MBS 0 Unspecified drop>PCR | ATM-GFR.1 PCR CDVT MCR MBS 0 Unspecified drop>PCR | |||
ATM-GFR.2 PCR CDVT MCR MBS 0 Unspecified drop>PCR | ATM-GFR.2 PCR CDVT MCR MBS 0 Unspecified drop>PCR | |||
mark>MCR,MFS | mark>MCR,MFS | |||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 35Internet Draft Constraint-Based LSP Setup using LDP July 2000 | Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 35 | |||
int-serv-CL p m r b 0 Frequent drop>p | int-serv-CL p m r b 0 Frequent drop>p | |||
drop>r,b | drop>r,b | |||
S= User specified | S= User specified | |||
In the above table, the DS refers to a delay sensitive service where | In the above table, the DS refers to a delay sensitive service where | |||
the network commits to deliver with high probability user datagrams | the network commits to deliver with high probability user datagrams | |||
at a rate of PDR with minimum delay and delay requirements. | at a rate of PDR with minimum delay and delay requirements. | |||
Datagrams in excess of PDR will be discarded. | Datagrams in excess of PDR will be discarded. | |||
skipping to change at line 1860 | skipping to change at line 1828 | |||
the edge. The specification of those actions is expected to be a | the edge. The specification of those actions is expected to be a | |||
part of the service level agreement (SLA) negotiation and is not | part of the service level agreement (SLA) negotiation and is not | |||
included in the signaling protocol. For DS service, the edge action | included in the signaling protocol. For DS service, the edge action | |||
is to drop packets that exceed the PDR and the PBS specifications. | is to drop packets that exceed the PDR and the PBS specifications. | |||
The signaling message will be sent in the direction of the ER path | The signaling message will be sent in the direction of the ER path | |||
and the LSP is established following the normal LDP procedures. Each | and the LSP is established following the normal LDP procedures. Each | |||
LSR applies its admission control rules. If sufficient resources are | LSR applies its admission control rules. If sufficient resources are | |||
not available and the parameter values are subject to negotiation, | not available and the parameter values are subject to negotiation, | |||
then the LSR could negotiate down the PDR, the PBS, or both. | then the LSR could negotiate down the PDR, the PBS, or both. | |||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 36Internet Draft Constraint-Based LSP Setup using LDP July 2000 | Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 36 | |||
The new parameter values are echoed back in the Label Mapping | The new parameter values are echoed back in the Label Mapping | |||
Message. LSRs might need to re-adjust their resource reservations | Message. LSRs might need to re-adjust their resource reservations | |||
based on the new traffic parameter values. | based on the new traffic parameter values. | |||
B.3 Establishing CR-LSP Supporting Delay Insensitive Applications | B.3 Establishing CR-LSP Supporting Delay Insensitive Applications | |||
In this example we assume that a throughput sensitive (TS) service | In this example we assume that a throughput sensitive (TS) service | |||
is requested. For resource allocation the user assigns values for | is requested. For resource allocation the user assigns values for | |||
PDR, PBS, CDR, and CBS. The negotiation flag is set if the traffic | PDR, PBS, CDR, and CBS. The negotiation flag is set if the traffic | |||
parameters are subject to negotiation. | parameters are subject to negotiation. | |||
skipping to change at line 1891 | skipping to change at line 1858 | |||
high discard precedence values for all packets that exceed CDR and | high discard precedence values for all packets that exceed CDR and | |||
the CBS. The edge rules will also include dropping of packets that | the CBS. The edge rules will also include dropping of packets that | |||
conform to neither PDR nor PBS. | conform to neither PDR nor PBS. | |||
Each LSR of the LSP is expected to run its admission control rules | Each LSR of the LSP is expected to run its admission control rules | |||
and negotiate traffic parameters down if sufficient resources do not | and negotiate traffic parameters down if sufficient resources do not | |||
exist. The new parameter values are echoed back in the Label Mapping | exist. The new parameter values are echoed back in the Label Mapping | |||
Message. LSRs might need to re-adjust their resources based on the | Message. LSRs might need to re-adjust their resources based on the | |||
new traffic parameter values. | new traffic parameter values. | |||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 37Internet Draft Constraint-Based LSP Setup using LDP July 2000 | Jamoussi, et. al. draft-ietf-mpls-cr-ldp-04.txt 37 | |||
Full Copyright Statement | Full Copyright Statement | |||
_Copyright c The Internet Society (date). All Rights Reserved. This | "Copyright ¨ The Internet Society (date). All Rights Reserved. This | |||
document and translations of it may be copied and furnished to | document and translations of it may be copied and furnished to | |||
others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
kind, provided that the above copyright notice and this paragraph | kind, provided that the above copyright notice and this paragraph | |||
are included on all such copies and derivative works. However, this | are included on all such copies and derivative works. However, this | |||
document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||
the copyright notice or references to the Internet Society or other | the copyright notice or references to the Internet Society or other | |||
Internet organizations, except as needed for the purpose of | Internet organizations, except as needed for the purpose of | |||
developing Internet standards in which case the procedures for | developing Internet standards in which case the procedures for | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |