draft-ietf-mpls-cr-ldp-01.txt | draft-ietf-mpls-cr-ldp-02.txt | |||
---|---|---|---|---|
MPLS WG Bilel Jamoussi, Editor | ||||
MPLS Working Group Bilel Jamoussi, Editor | Internet Draft Nortel Networks Corp. | |||
Internet Draft Nortel Networks | Expiration Date: February 2000 | |||
Expiration Date: August 1999 | August 1999 | |||
February 1999 | ||||
Constraint-Based LSP Setup using LDP | Constraint-Based LSP Setup using LDP | |||
draft-ietf-mpls-cr-ldp-01.txt | draft-ietf-mpls-cr-ldp-02.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 months | Internet-Drafts are draft documents valid for a maximum of six | |||
and may be updated, replaced, or obsoleted by other documents at any | months and may be updated, replaced, or obsoleted by other documents | |||
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. | |||
Distribution of this memo is unlimited. | ||||
Copyright Notice | ||||
Copyright (C) The Internet Society (1998). All Rights Reserved. | ||||
Abstract | Abstract | |||
Label Distribution Protocol (LDP) is defined in [LDP] for | Label Distribution Protocol (LDP) is defined in [1] for distribution | |||
distribution of labels inside one MPLS domain. One of the most | of labels inside one MPLS domain. One of the most important | |||
important services that may be offered using MPLS in general and LDP | services that may be offered using MPLS in general and LDP in | |||
in particular is support for constraint-based routing of traffic | particular is support for constraint-based routing of traffic across | |||
across the routed network. Constraint-based routing offers the | the routed network. Constraint-based routing offers the opportunity | |||
opportunity to extend the information used to setup paths beyond what | to extend the information used to setup paths beyond what is | |||
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 | |||
others. Constraint-based routing (CR) is a mechanism used to meet | other constraints. Constraint-based routing (CR) is a mechanism used | |||
Traffic Engineering requirements that have been proposed by [FRAME], | to meet Traffic Engineering requirements that have been proposed by | |||
[ARCH] and [TER]. These requirements may be met by extending LDP for | [2], [3] and [4]. These requirements may be met by extending LDP for | |||
support of constraint-based routed label switched paths (CRLSPs). | support of constraint-based routed label switched paths (CRLSPs). | |||
Other uses exist for CRLSPs as well ([5], [6] and [7]). | ||||
CR-LDP Specification - 2 - Exp. August 1999 | ||||
Other uses exist for CRLSPs as well ([VPN1], [VPN2] and [VPN3]). | ||||
This draft specifies mechanisms and TLVs for support of CRLSPs using | This draft specifies mechanisms and TLVs for support of CRLSPs using | |||
LDP. The Explicit Route object and procedures are extracted from | LDP. The Explicit Route object and procedures are extracted from | |||
[ER]. | [8]. | |||
Table of Contents | Table of Contents | |||
1. Introduction ......................................... 3 | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 1 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
2. Constraint-based Routing Overview .................... 3 | ||||
2.1 Strict and Loose Explicit Routes ..................... 4 | ||||
2.2 Traffic Characteristics .............................. 4 | ||||
2.3 Pre-emption .......................................... 5 | ||||
2.4 Route Pinning ........................................ 5 | ||||
2.5 Resource Class ....................................... 5 | ||||
3. Solution Overview .................................... 5 | ||||
3.1 Required Messages and TLVs ........................... 7 | ||||
3.2 Label Request Message ................................ 7 | ||||
3.3 Label Mapping Message ................................ 8 | ||||
3.4 Notification Message ................................. 9 | ||||
3.5 Release & Withdraw Messages .......................... 9 | ||||
4. Protocol Specification .............................. 9 | ||||
4.1 Explicit Route TLV (ER-TLV) ......................... 10 | ||||
4.2 Explicit Route Hop TLV .............................. 10 | ||||
4.3 Traffic Parameters TLV .............................. 12 | ||||
4.3.1 Semantics ........................................... 13 | ||||
4.3.1.1 Frequency ........................................... 13 | ||||
4.3.1.2 Peak Rate ........................................... 14 | ||||
4.3.1.3 Committed Rate ...................................... 14 | ||||
4.3.1.4 Excess Burst Size .................................... 14 | ||||
4.3.1.5 Peak Rate Token Bucket................................ 14 | ||||
4.3.1.6 Committed Data Rate Token Bucket ..................... 15 | ||||
4.3.1.7 Weight ......................... ..................... 16 | ||||
4.3.2 Procedures ........................................... 16 | ||||
4.3.2.1 Label Request Message ................................ 16 | ||||
4.3.2.2 Label Mapping Message ................................ 16 | ||||
4.3.2.3 Notification Message ................................. 17 | ||||
4.4 Preemption TLV ....................................... 18 | ||||
4.5 LSPID TLV ........................................... 18 | ||||
4.6 Resource Class TLV .................................. 19 | ||||
4.7 ER-Hop Semantics ..................................... 19 | ||||
4.7.1 ER-Hop 1 TLV IPv4 Prefix ............................. 20 | ||||
4.7.2 ER-Hop 2 TLV IPv6 Prefix ............................. 20 | ||||
4.7.3 ER-Hop 3 TLV AS Number ............................... 21 | ||||
4.7.4 ER-Hop 4 TLV LSPID ................................... 21 | ||||
4.8 Processing of the ER-TLV ............................. 22 | ||||
4.8.1 Selection of the next hop ............................ 22 | ||||
4.8.2 Adding the Label Request Message to the next hop ..... 24 | ||||
4.9 Route Pinning TLV ................................... 24 | ||||
4.10 CR-LSP FEC Element ................................... 24 | ||||
4.11 Error Subcodes ...................................... 25 | ||||
CR-LDP Specification - 3 - Exp. August 1999 | ||||
5. Security Considerations .............................. 26 | 1. Introduction....................................................3 | |||
6. Acknowledgement ...................................... 26 | 2. Constraint-based Routing Overview...............................3 | |||
7. References ........................................... 26 | 2.1 Strict and Loose Explicit Routes...............................3 | |||
8. Author Information ................................... 28 | 2.2 Traffic Characteristics........................................4 | |||
2.3 Pre-emption....................................................4 | ||||
2.4 Route Pinning..................................................5 | ||||
2.5 Resource Class.................................................5 | ||||
3. Solution Overview...............................................5 | ||||
3.1 Required Messages and TLVs.....................................6 | ||||
3.2 Label Request Message..........................................7 | ||||
3.3 Label Mapping Message..........................................7 | ||||
3.4 Notification Message...........................................8 | ||||
3.5 Release , Withdraw, and Abort Messages.........................9 | ||||
4. Protocol Specification..........................................9 | ||||
4.1 Explicit Route TLV (ER-TLV)....................................9 | ||||
4.2 Explicit Route Hop TLV (ER-Hop TLV)...........................10 | ||||
4.3 Traffic Parameters TLV........................................11 | ||||
4.3.1 Semantics...................................................13 | ||||
4.3.1.1 Frequency.................................................13 | ||||
4.3.1.2 Peak Rate.................................................13 | ||||
4.3.1.3 Committed Rate............................................13 | ||||
4.3.1.4 Excess Burst Size.........................................14 | ||||
4.3.1.5 Peak Rate Token Bucket....................................14 | ||||
4.3.1.6 Committed Data Rate Token Bucket..........................14 | ||||
4.3.1.7 Weight....................................................15 | ||||
4.3.2 Procedures..................................................15 | ||||
4.3.2.1 Label Request Message.....................................15 | ||||
4.3.2.2 Label Mapping Message.....................................16 | ||||
4.3.2.3 Notification Message......................................16 | ||||
4.4 Preemption TLV................................................16 | ||||
4.5 LSPID TLV.....................................................17 | ||||
4.6 Resource Class (Color) TLV....................................18 | ||||
4.7 ER-Hop semantics..............................................19 | ||||
4.7.1. ER-Hop 1: The IPv4 prefix..................................19 | ||||
4.7.2. ER-Hop 2: The IPv6 address.................................19 | ||||
4.7.3. ER-Hop 3: The autonomous system number....................20 | ||||
4.7.4. ER-Hop 4: LSPID............................................20 | ||||
4.8. Processing of the Explicit Route TLV.........................22 | ||||
4.8.1. Selection of the next hop..................................22 | ||||
4.8.2. Adding ER-Hops to the explicit route TLV...................23 | ||||
4.9 Route Pinning TLV.............................................23 | ||||
4.10 CRLSP FEC Element............................................24 | ||||
4.11 Error subcodes...............................................24 | ||||
5. Security.......................................................25 | ||||
6. Acknowledgments................................................25 | ||||
7. Intellectual Property Consideration............................25 | ||||
8. References.....................................................25 | ||||
9. Author's Addresses.............................................26 | ||||
Appendix A: CRLSP Establishment Examples..........................29 | ||||
A.1 Strict Explicit Route Example.................................29 | ||||
A.2. Node Groups and Specific Nodes Example.......................30 | ||||
Appendix A CRLSP Establishment Examples ......................... 30 | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 2 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
A.1 Strict Explicit Route Example ........................ 30 | ||||
A.2 Node Groups and Specific Nodes Example ............... 31 | ||||
Appendix B QoS Service Examples ................................. 34 | Appendix B. QoS Service Examples..................................33 | |||
B.1 Service Examples ..................................... 34 | B.1 Service Examples..............................................33 | |||
B.2 Establishing CR-LSP Supporting Real-Time Applications. 35 | B.2. Establishing CR-LSP Supporting Real-Time Applications........34 | |||
B.3 Establishing CR-LSP Delay Insensitive Applications ... 36 | B.3. Establishing CR-LSP Supporting Delay Insensitive Applications35 | |||
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 [ARCH], [FRAME], and [TER]. Explicit routing is a subset | elsewhere [3], [2], and [4]. Explicit routing is a subset of the | |||
of the more general constraint-based routing function. At the MPLS WG | more general constraint-based routing function. At the MPLS WG | |||
meeting held during the Washington IETF there was consensus that LDP | meeting held during the Washington IETF (December 1997) there was | |||
should support explicit routing of LSPs with provision for indication | consensus that LDP should support explicit routing of LSPs with | |||
of associated (forwarding) priority. In the Chicago meeting, a | provision for indication of associated (forwarding) priority. In | |||
decision was made that support for explicit path setup in LDP will be | the Chicago meeting (August 1998), a decision was made that support | |||
moved to a separate document. This document provides that support and | for explicit path setup in LDP will be moved to a separate document. | |||
it has been accepted as a working document in the Orlando meeting. | This document provides that support and it has been accepted as a | |||
working 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 (CRLSP) initiated by the ingress LSR. We | constraint-based routed LSP (CRLSP) initiated by the ingress LSR. We | |||
also specify mechanisms to provide means for reservation of resources | also specify mechanisms to provide means for reservation of | |||
using LDP. | resources using LDP. | |||
This document introduce TLVs and procedures that provide support for: | ||||
This document introduce TLVs and procedures that provide support | ||||
for: | ||||
- Strict and Loose Explicit Routing | - Strict and Loose Explicit Routing | |||
- Specification of Traffic Parameters | - Specification of Traffic Parameters | |||
- Route Pinning | - Route Pinning | |||
- CRLSP Pre-emption though setup/holding priorities | - CRLSP Pre-emption though setup/holding priorities | |||
- Handling Failures | - Handling Failures | |||
- LSPID | - LSPID | |||
- Resource Class | - Resource Class | |||
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 routed | defines the TLVs and procedures used to setup constraint-based | |||
label switched paths. Appendix A provides several examples of CR-LSP | routed label switched paths. Appendix A provides several examples | |||
path setup. Appendix B provides Service Definition Examples. | of CR-LSP path setup. Appendix B provides Service Definition | |||
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 [TER]. Explicit Routing is a | 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 | |||
CR-LDP Specification - 4 - Exp. August 1999 | ||||
constraint is the explicit route (ER). Other constraints are defined | constraint is the explicit route (ER). Other constraints are defined | |||
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 supported | LSP. This section is an overview of the various constraints | |||
by this specification. | supported by this specification. | |||
2.1 Strict and Loose Explicit Routes | 2.1 Strict and Loose Explicit Routes | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 3 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
Like any other LSP an CRLSP is a path through an MPLS network. The | Like any other LSP an CRLSP 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 | |||
desired special characteristics to the LSP in order to better support | desired special characteristics to the LSP in order to better | |||
the traffic sent over the LSP. The reason for setting up CRLSPs, | support the traffic sent over the LSP. The reason for setting up | |||
might be that one wants to assign certain bandwidth or other Service | CRLSPs, might be that one wants to assign certain bandwidth or other | |||
Class characteristics to the LSP, or that one wants to make sure that | Service Class characteristics to the LSP, or that one wants to make | |||
alternative routes use physically separate paths through the network. | sure that alternative routes use physically separate paths through | |||
the network. | ||||
An explicit route is represented in a Label Request Message as a | An explicit route is represented in a Label Request Message as a | |||
list of nodes or groups of nodes along the constraint-based route. | list of nodes or groups of nodes along the constraint-based route. | |||
When the CRLSP is established, all or a subset of the nodes in a | When the CRLSP is established, all or a subset of the nodes in a | |||
group may be traversed by the LSP. Certain operations to be | group may be traversed by the LSP. Certain operations to be | |||
performed along the path can also be encoded in the constraint-based | performed along the path can also be encoded in the constraint-based | |||
route. | route. | |||
The capability to specify, in addition to specified nodes, groups of | The capability to specify, in addition to specified nodes, groups of | |||
nodes, of which a subset will be traversed by the CRLSP, allows the | nodes, of which a subset will be traversed by the CRLSP, allows the | |||
system a significant amount of local flexibility in fulfilling a | system a significant amount of local flexibility in fulfilling a | |||
request for a constraint-based route. This allows the generator of | request for a constraint-based route. This allows the generator of | |||
the constraint-based route to have some degree of imperfect | the constraint-based route to have some degree of imperfect | |||
information about the details of the path. | information about the details of the path. | |||
The constraint-based route is encoded as a series of ER-Hops | The constraint-based route is encoded as a series of ER-Hops | |||
contained in a constraint-based route TLV. Each ER-Hop may identify | contained in a constraint-based route TLV. Each ER-Hop may identify | |||
a group of nodes in the constraint-based route. A constraint-based | a group of nodes in the constraint-based route. A constraint-based | |||
route is then a path including all of the identified groups of nodes. | route is then a path including all of the identified groups of | |||
nodes. | ||||
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 | |||
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 CRLDP MPLS | specify a constraint on the delay variation that the CRLDP MPLS | |||
domain may introduce to a path's traffic. | domain may introduce to a path's traffic. | |||
CR-LDP Specification - 5 - Exp. August 1999 | ||||
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 | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 4 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
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 the | priorities are used to rank existing paths (holding priority) and | |||
new path (setup priority) to determine if the new path can pre-empt | the new path (setup priority) to determine if the new path can pre- | |||
an existing path. | empt an existing path. | |||
The setupPriority of a new CRLSP and the holdingPriority attributes | The setupPriority of a new CRLSP and the holdingPriority attributes | |||
of the existing CRLSP are used to specify priorities. Signaling a | of the existing CRLSP are used to specify priorities. Signaling a | |||
higher holding priority expresses that the path, once it has been | higher holding priority express that the path, once it has been | |||
established, should have a lower chance of being pre-empted. | established, should have a lower chance of being pre-empted. | |||
Signaling a higher setup priority expresses the expectation that, in | Signaling a higher setup priority expresses the expectation that, in | |||
the case that resource are unavailable, the path is more likely to | the case that resource are unavailable, the path is more likely to | |||
pre-empt other paths. The exact rules determining bumping are an | pre-empt other paths. The exact rules determining bumping are an | |||
aspect of network policy. | aspect of network policy. | |||
The allocation of setup and holding priority values to paths is an | The allocation of setup and holding priority values to paths is an | |||
aspect of network policy. | aspect of network policy. | |||
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. | priority values is an aspect of network policy. | |||
The setupPriority of a CRLSP should not be higher (numerically less) | The setupPriority of a CRLSP should not be higher (numerically less) | |||
than its holdingPriority since it might bump an LSP and be bumped by | than its holdingPriority since it might bump an LSP and be bumped by | |||
next "equivalent" request. | 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 with | routed - i.e. those segments which are specified with a next hop | |||
the 'L' bit set or where the next hop is an "abstract node". A CRLSP | with the `L' bit set or where the next hop is an _abstract node_. A | |||
may be setup using route pinning if it is undesirable to change the | CRLSP may be setup using route pinning if it is undesirable to | |||
path used by an LSP because a better next hop becomes available at | change the path used by an LSP because a better next hop becomes | |||
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 | |||
Network resources may be classified in various ways by the network | The network operator may classify network resources in various ways. | |||
operator. These classes are also known as "colors" or "administrative | These classes are also known as _colors_ or _administrative groups_. | |||
groups". When an CR-LSP is being established, it's necessary to | When an CR-LSP is being established, it's necessary to indicate | |||
indicate which resource classes the CR-LSP can draw from. | which resource classes the CR-LSP can draw from. | |||
3. Solution Overview | 3. Solution Overview | |||
CRLSP over LDP Specification is designed with the following goals: | CRLSP over LDP Specification is designed with the following goals: | |||
CR-LDP Specification - 6 - Exp. August 1999 | 1. Meet the requirements outlined in [4] for performing traffic | |||
engineering and provide a solid foundation for performing | ||||
more general constraint-based routing. | ||||
1. Meet the requirements outlined in [TER] for performing traffic | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 5 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
engineering and provide a solid foundation for performing more | ||||
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 specifications is | requirements whenever possible. Hence, this specification is | |||
based on [LDP] and the Explicit Route object and procedures | based on [1] and the Explicit Route object and procedures | |||
defined in [ER]. | defined in [8]. | |||
3. Keep the solution simple. | 3. Keep the solution simple. | |||
In this document, support for unidirectional point-to-point CRLSPs is | In this document, support for unidirectional point-to-point CRLSPs | |||
specified. Support for point-to-multipoint, multipoint-to-point, is | is specified. Support for point-to-multipoint, multipoint-to-point, | |||
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 [LDP]: | depends on the following minimal LDP behaviors as specified in [1]: | |||
- Basic and/or Extended Discovery Mechanisms. | - Basic and/or Extended Discovery Mechanisms. | |||
- Use the Label Request Message defined in [1] in downstream on | ||||
- Use the Label Request Message defined in [LDP] in downstream on | ||||
demand label advertisement mode with ordered control. | demand label advertisement mode with ordered control. | |||
- Use the Label Mapping Message defined in [1] in downstream on | ||||
- Use the Label Mapping Message defined in [LDP] in downstream on | ||||
demand mode with ordered control. | demand mode with ordered control. | |||
- Use the Notification Message defined in [1]. | ||||
- Use the Notification Message defined in [LDP]. | - Use the Withdraw and Release Messages defined in [1]. | |||
- Use the Withdraw and Release Messages defined in [LDP]. | ||||
- Use the Loop Detection (in the case of loosely routed segments | - Use the Loop Detection (in the case of loosely routed segments | |||
of a CRLSP) mechanisms defined in [LDP]. | of a CRLSP) 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 [LDP]: | in [1]: | |||
- The Label Request Message used to setup a CRLSP includes one or | - The Label Request Message used to setup a CRLSP includes one or | |||
more CR-TLVs defined in Section 4. For instance, the Label Request | more CR-TLVs defined in Section 4. For instance, the Label | |||
Message may include the ER-TLV. | Request 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 that | one or more CR-TLVs in the Label Request Message. This means | |||
the LSR can still be configured for independent control for LSPs | that the LSR can still be configured for independent control | |||
established as a result of dynamic routing. However, when a Label | for LSPs established as a result of dynamic routing. However, | |||
Request Message includes one or more of the CR-TLVs, then ordered | when a Label Request Message includes one or more of the CR- | |||
control is used to setup the CRLSP. Note that this is also true | TLVs, then ordered control is used to setup the CRLSP. Note | |||
for the loosely routed parts of a CRLSP. | that this is also true for the loosely routed parts of a CRLSP. | |||
- 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-TLV. | failure of established paths specified in the CR-TLV. | |||
CR-LDP Specification - 7 - Exp. August 1999 | Optional TLVs are not required in the CR-LDP messages for the | |||
messages to be compliant with the protocol. Optional parameters CAN | ||||
be required for a particular operation to work (or work correctly), | ||||
however. | ||||
Examples of CRLSP establishment are given in Appendix A to illustrate | Examples of CRLSP establishment are given in Appendix A to | |||
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 | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 6 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
document are defined in the [LDP] Specification. The state | ||||
transitions which relate to CR-LDP messages can be found in [LDP- | ||||
STATE]. | ||||
The following subsections are meant as a cross reference to the [LDP] | Any Messages, TLVs, and procedures not defined explicitly in this | |||
document are defined in the LDP Specification [1]. The state | ||||
transitions, which relate to CR-LDP messages, can be found in [9]. | ||||
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 [LDP] where necessary. | defined in [1] where necessary. | |||
3.2 Label Request Message | 3.2 Label Request Message | |||
The Label Request Message is as defined in 3.5.8 of [LDP] 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): | |||
- Only a single FEC-TLV may be included in the Label Request | - Only a single FEC-TLV may be included in the Label Request | |||
Message. The CR-LSP FEC TLV should be used. | Message. The CR-LSP FEC TLV should be used. | |||
- The Return Message ID TLV is MANDATORY. | ||||
- 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 augmented | - The Procedures to handle the Label Request Message are | |||
by the procedures for processing of the CR-TLVs as defined in | augmented by the procedures for processing of the CR-TLVs as | |||
Section 4. | defined in 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: | |||
CR-LDP Specification - 8 - Exp. August 1999 | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U| Label Request (0x0401) | Message Length | | |0| Label Request (0x0401) | Message Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Message ID | | | Message ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| FEC TLV | | | FEC TLV | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Return Message ID TLV (mandatory) | | | Message ID TLV (mandatory) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| LSPID TLV (CR-LDP, mandatory) | | | LSPID TLV (CR-LDP, mandatory) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 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) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
3.3 Label Mapping Message | 3.3 Label Mapping Message | |||
The Label Mapping Message is as defined in 3.5.7 of [LDP] with the | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 7 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
The Label Mapping Message is as defined in 3.5.7 of [1] with the | ||||
following modifications: | following modifications: | |||
- Only a single Label-TLV may be included in the Label Mapping | - Only a single Label-TLV may be included in the Label Mapping | |||
Message. | Message. | |||
- The Label Mapping Message MUST include Label Request Message ID | ||||
TLV. | ||||
- The Label Mapping Message MUST include LSPID TLV. | ||||
- 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 CRLSP and an upstream mapping | 1. The LSR is the egress end of the CRLSP and an upstream | |||
has been requested. | mapping has been requested. | |||
2. The LSR received a mapping from its downstream next hop LSR for | 2. The LSR received a mapping from its downstream next hop LSR | |||
an CRLSP for which an upstream request is still pending. | for an CRLSP for which an upstream request is still 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: | |||
CR-LDP Specification - 9 - Exp. August 1999 | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U| 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 (mandatory) | | | Label Request Message ID TLV | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| LSPID TLV (CR-LDP, mandatory) | | | LSPID TLV (CR-LDP, optional) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Traffic TLV (CR-LDP, optional) | | | Traffic TLV (CR-LDP, optional) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
3.4 Notification Message | 3.4 Notification Message | |||
The Notification Message is as defined in Section 3.5.1 of [LDP] 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.7 of [LDP]. | the Status TLV encoding is as defined in Section 3.4.7 of [1]. | |||
Establishment of an Explicitly Routed LSP may fail for a variety of | Establishment of an Explicitly Routed LSP may fail for a variety of | |||
reasons. All such failures are considered advisory conditions and | reasons. All such failures are considered advisory conditions and | |||
they are signaled by the Notification Message. | they are 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 CRLSP and | error notifications associated with the establishment of a CRLSP and | |||
the processing of the CR-TLV. | the processing of the CR-TLV. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 8 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
The Notification Message must carry the LSPID TLV of the | The Notification Message must carry the LSPID TLV of the | |||
corresponding CRLSP. | corresponding CRLSP. | |||
3.5 Release and Withdraw Messages | Notification Messages MUST be forwarded toward the LSR originating | |||
the Label Request at each hop and at any time that procedures in | ||||
this specification - or in [1] - specify sending of a Notification | ||||
Message in response to a Label Request Message. | ||||
The Label Release and Label Withdraw Messages are used as specified | The encoding of the notification message is as follows: | |||
in [LDP] to clear CR-LSPs. These message may also carry the LSPID | ||||
TLV. | 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| Notification (0x0001) | Message Length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Message ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Status (TLV) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Optional Parameters | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
3.5 Release , Withdraw, and Abort Messages | ||||
The Label Release , Label Withdraw, and Label Abort Request Messages | ||||
are used as specified in [1]. These messages may also carry the | ||||
LSPID TLV. | ||||
4. Protocol Specification | 4. Protocol Specification | |||
The Label Request Messages defined in [LDP] optionally carries one or | The Label Request Messages defined in [1] optionally carries one or | |||
more of the optional Constraint-based Routing TLVs (CR-TLVs) defined | more of the optional Constraint-based Routing TLVs (CR-TLVs) defined | |||
in this section. If needed, other constraints can be supported later | in this section. If needed, other constraints can be supported later | |||
through the definition of new TLVs. In this specification, the | through the definition of new TLVs. In this specification, the | |||
following TLVs are defined: | following TLVs are defined: | |||
- Explicit Route TLV | - Explicit Route TLV | |||
CR-LDP Specification - 10 - Exp. August 1999 | ||||
- Explicit Route Hop TLV | - Explicit Route Hop TLV | |||
- Traffic Parameters TLV | - Traffic Parameters TLV | |||
- Preemption TLV | - Preemption TLV | |||
- LSPID TLV | - LSPID TLV | |||
- Route Pinning TLV | - Route Pinning TLV | |||
- Resource Class TLV | - Resource Class TLV | |||
- CRLSP FEC TLV | - CRLSP 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. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 9 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| ER-TLV (0x0800) | Length | | |0|0| ER-TLV (0x0800) | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ER-Hop TLV 1 | | | ER-Hop TLV 1 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ER-Hop TLV 2 | | | ER-Hop TLV 2 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ ............ ~ | ~ ............ ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ER-Hop TLV n | | | ER-Hop TLV n | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | ||||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
Type | Type | |||
A two byte field carrying the value of the ER-TLV type which | A two-byte field carrying the value of the ER-TLV type whichis | |||
is 0x800. | 0x800. | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
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. Each ER-Hop TLV has the form: | TLVs. | |||
CR-LDP Specification - 11 - Exp. August 1999 | A node receiving a label request message including an ER-Hop type | |||
that is not supported should not progress the label request message | ||||
to the downstream LSR and should send back a _No Route_ Notification | ||||
Message. | ||||
Each ER-Hop TLV has the form: | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| ER-Hop-Type | Length | | |0|0| ER-Hop-Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L| Content // | | |L| Content // | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | ||||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
ER-Hop Type | ER-Hop Type | |||
A fourteen-bit field indicating the type of contents of | A fourteen-bit field indicating the type of contents of the ER- | |||
the ER-Hop. Currently defined values are: | Hop. Currently defined values are: | |||
Value Type | Value Type | |||
----- ------------------------ | ----- ------------------------ | |||
0x801 IPv4 prefix | 0x801 IPv4 prefix | |||
0x802 IPv6 prefix | 0x802 IPv6 prefix | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 10 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
0x803 Autonomous system number | 0x803 Autonomous system number | |||
0x804 LSPID | 0x804 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 is an attribute of the ER-Hop. The L bit is set if the | The L bit is an attribute of the ER-Hop. The L bit is set if | |||
ER-Hop represents a loose hop in the explicit route. If the bit is | the ER-Hop ER-Hop represents a loose hop in the explicit route. | |||
not set, the ER-Hop represents a strict hop in the explicit route. | If the bit is not set, the ER-Hop represents a strict hop in | |||
the explicit route. | ||||
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, 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 "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 strict or a | ||||
loose node, respectively. Loose and strict nodes are always | ||||
interpreted relative to their prior abstract nodes. | ||||
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, | ||||
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 | ||||
_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 | ||||
strict or a loose node, respectively. Loose and strict 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 other | The path between a loose node and its prior node MAY include | |||
network nodes which are not part of the strict node or its prior | other network nodes, which are not part of the strict node or | |||
abstract node. | its prior abstract node. | |||
CR-LDP Specification - 12 - Exp. August 1999 | ||||
Contents | Contents | |||
A variable length field containing the node or abstract node that | A variable length field containing the node or abstract node | |||
is the consecutive nodes that make up the explicit routed LSP. | that is the consecutive nodes that make up the explicit routed | |||
LSP. | ||||
4.3 Traffic Parameters TLV | 4.3 Traffic Parameters TLV | |||
The following sections describe the CRLSP Traffic Parameters. The | The following sections describe the CRLSP Traffic Parameters. The | |||
required characteristics of a CRLSP are expressed by the Traffic | required characteristics of a CRLSP 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. | |||
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. The | Weight, and the five Traffic Parameters PDR, PBS, CDR, CBS, EBS. | |||
Traffic Parameters TLV is shown below: | The Traffic Parameters TLV is shown below: | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 11 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| Traf. Param. TLV (0x0810)| Length | | |0|0| Traf. Param. TLV (0x0810)| Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Flags | Frequency | Reserved | Weight | | | Flags | Frequency | Reserved | Weight | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Peak Data Rate (PDR) | | | Peak Data Rate (PDR) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Peak Burst Size (PBS) | | | Peak Burst Size (PBS) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Committed Data Rate (CDR) | | | Committed Data Rate (CDR) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Committed Burst Size (CBS) | | | Committed Burst Size (CBS) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Excess Burst Size (EBS) | | | Excess Burst Size (EBS) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | ||||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
Type | Type | |||
A fourteen-bit field carrying the value of the ER-TLV type which | A fourteen-bit field carrying the value of the ER-TLV type | |||
is 0x810. | which is 0x810. | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
Flags | Flags | |||
The Flags field is shown below: | The Flags field is shown below: | |||
CR-LDP Specification - 13 - Exp. August 1999 | ||||
+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+ | |||
| Res |F6|F5|F4|F3|F2|F1| | | Res |F6|F5|F4|F3|F2|F1| | |||
+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+ | |||
Res - These bits are reserved. | Res - These bits are reserved. | |||
Zero on transmission. | Zero on transmission. | |||
Ignored on receipt. | Ignored on receipt. | |||
F1 - Corresponds to the PDR. | F1 - Corresponds to the PDR. | |||
F2 - Corresponds to the PBS. | F2 - Corresponds to the PBS. | |||
F3 - Corresponds to the CDR. | F3 - Corresponds to the CDR. | |||
skipping to change at page 13, line 31 | skipping to change at line 640 | |||
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 | |||
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 | |||
2 - VeryFrequest | ||||
3-255 - Reserved | ||||
Reserved | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 12 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
2- VeryFrequest 3-255 - Reserved Reserved | ||||
Zero on transmission. Ignored on receipt. | Zero on transmission. Ignored on receipt. | |||
Weight | Weight | |||
An 8 bit unsigned integer indicating the weight of the CRLSP. | An 8 bit unsigned integer indicating the weight of the CRLSP. | |||
Valid weight values are from 1 to 255. The value 0 means | Valid weight values are from 1 to 255. The value 0 means that | |||
that weight is not applicable for the CRLSP. | weight is not applicable for the CRLSP. | |||
Traffic Parameters | Traffic Parameters | |||
Each Traffic Parameter is encoded as a 32 bit IEEE single- | Each Traffic Parameter is encoded as a 32-bit IEEE single- | |||
precision floating point number. A value of positive infinity is | precision floating-point number. A value of positive infinity | |||
represented as an IEEE single-precision floating-point number with | is represented as an IEEE single-precision floating-point | |||
an exponent of all ones (255) and a sign and mantissa of all | number with an exponent of all ones (255) and a sign and | |||
zeros. The values PDR and CDR are in units of bytes per second. | mantissa of all zeros. The values PDR and CDR are in units of | |||
The values PBS, CBS and EBS are in units of bytes. | bytes per second. The values PBS, CBS and EBS are in units of | |||
bytes. | ||||
The value of PDR MUST be greater than or equal to the value of CDR | The value of PDR MUST be greater than or equal to the value of | |||
in a correctly encoded Traffic Parameters TLV. | CDR in a correctly encoded Traffic Parameters TLV. | |||
4.3.1 Semantics | 4.3.1 Semantics | |||
4.3.1.1 Frequency | 4.3.1.1 Frequency | |||
CR-LDP Specification - 14 - Exp. August 1999 | ||||
The Frequency specifies at what granularity the CDR allocated to the | The Frequency specifies at what granularity the CDR allocated to the | |||
CRLSP is made available. The value VeryFrequently means that the | CRLSP is made available. The value VeryFrequently means that the | |||
available rate should average at least the CDR when measured over any | available rate should average at least the CDR when measured over | |||
time interval equal to or longer than the shortest packet time at the | any time interval equal to or longer than the shortest packet time | |||
CDR. The value Frequently means that the available rate should | at the CDR. The value Frequently means that the available rate | |||
average at least the CDR when measured over any time interval equal | should average at least the CDR when measured over any time interval | |||
to or longer than a small number of shortest packet times at the CDR. | equal to or longer than a small number of shortest packet times at | |||
the CDR. | ||||
The value Unspecified means that the CDR MAY be provided at any | The value Unspecified means that the CDR MAY be provided at any | |||
granularity. | granularity. | |||
4.3.1.2 Peak Rate | 4.3.1.2 Peak Rate | |||
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 CRLSP. The Peak Rate is useful for the purpose of | sent to the CRLSP. 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. | |||
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 CRLSP. | be available to the CRLSP. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 13 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
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 CRLSP exceeds the committed | the extent by which the traffic sent on a CRLSP exceeds the | |||
rate. | committed rate. | |||
The possible traffic conditioning actions, such as passing, marking | The possible traffic conditioning actions, such as passing, marking | |||
or dropping, are specific to the MPLS domain. | or dropping, are specific to the MPLS domain. | |||
The Excess Burst Size is defined together with the Committed Rate, | The Excess Burst Size is defined together with the Committed Rate, | |||
see section 4.3.1.6 below. | see section 4.3.1.6 below. | |||
4.3.1.5 Peak Rate Token Bucket | 4.3.1.5 Peak Rate Token Bucket | |||
The Peak Rate of a CRLSP is specified in terms of a token bucket P | The Peak Rate of a CRLSP is specified in terms of a token bucket P | |||
with token rate PDR and maximum token bucket size PBS. | with token rate PDR and maximum token bucket size PBS. | |||
The token bucket P is initially (at time 0) full, i.e., the token | The token bucket P is initially (at time 0) full, i.e., the token | |||
count Tp(0) = PBS. Thereafter, the token count Tp, if less than PBS, | count Tp(0) = PBS. Thereafter, the token count Tp, if less than | |||
is incremented by one PDR times per second. When a packet of size B | PBS, is incremented by one PDR times per second. When a packet of | |||
bytes arrives at time t, the following happens: | size B bytes arrives at time t, the following happens: | |||
CR-LDP Specification - 15 - Exp. August 1999 | ||||
o If Tp(t)-B >= 0, the packet is not in excess of the peak | - If Tp(t)-B >= 0, the packet is not in excess of the peak rate | |||
rate and Tp is decremented by B down to the minimum value | and Tp is decremented by B down to the minimum value of 0, else | |||
of 0, else | ||||
o the packet is in excess of the peak rate and Tp is | - the packet is in excess of the peak rate and Tp is not | |||
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 in | value of either PDR or PBS implies that arriving packets are ever in | |||
excess of the peak rate. | excess of the peak rate. | |||
The actual implementation of a LSR doesn't need to be modeled | The actual implementation of a 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 CRLSP is specified in terms of a token bucket | The committed rate of a CRLSP is specified in terms of a token | |||
C with rate CDR. The extent by which the offered rate exceeds the | bucket C with rate CDR. The extent by which the offered rate | |||
committed rate MAY be measured in terms of another token bucket E, | exceeds the committed rate MAY be measured in terms of another token | |||
which also operates at rate CDR. The maximum size of the token | bucket E, which also operates at rate CDR. The maximum size of the | |||
bucket C is CBS and the maximum size of the token bucket E is EBS. | token bucket C is CBS and the maximum size of the token bucket E is | |||
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. Thereafter, | token count Tc(0) = CBS and the token count Te(0) = EBS. | |||
the token counts Tc and Te are updated CDR times per second as | Thereafter, the token counts Tc and Te are updated CDR times per | |||
follows: | second as follows: | |||
o If Tc is less than CBS, Tc is incremented by one, else | ||||
o if Te is less then EBS, Te is incremented by one, else | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 14 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
o neither Tc nor Te is incremented. | - If Tc is less than CBS, Tc is incremented by one, else | |||
- if Te is less then EBS, Te is incremented by one, else | ||||
- 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: | |||
o 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 | Rate and Tc is decremented by B down to the minimum value of 0, | |||
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 | ||||
o 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 | to the minimum value of 0, else | |||
decremented by B down to the minimum value of 0, else | - the packet is in excess of both the Committed Rate and the EBS | |||
o the packet is in excess of both the Committed Rate and the EBS | ||||
and neither Tc nor Tc is decremented. | and neither Tc nor Tc 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 | |||
CR-LDP Specification - 16 - Exp. August 1999 | ||||
exceeded. | exceeded. | |||
The actual implementation of a LSR doesn't need to be modeled | The actual implementation of a 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 CRLSP's relative share of the possible | The weight determines the CRLSP'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 the | Parameters Unavailable to the upstream LSR from which it received | |||
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. | |||
If the Weight is indicated as Negotiable in the Label Request Message | If the Weight is indicated as Negotiable in the Label Request | |||
by the corresponding Negotiable Flag then an LSR may adjust replace | Message by the corresponding Negotiable Flag then an LSR may adjust | |||
the Weight value with a lower value (down to 1). | replace the Weight value with a lower value (down to 0). | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 15 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
If, after possible Traffic Parameter negotiation, an LSR can support | If, after possible Traffic Parameter negotiation, an LSR can support | |||
the CRLSP Traffic Parameters then the LSR MUST reserve the | the CRLSP Traffic Parameters then the LSR MUST reserve the | |||
corresponding resources for the CRLSP. | corresponding resources for the CRLSP. | |||
If, after possible Traffic Parameter negotiation, an LSR cannot | If, after possible Traffic Parameter negotiation, an LSR cannot | |||
support the CRLSP Traffic Parameters then the LSR MUST send a | support the CRLSP 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. | erroneous message. | |||
The egress LSR MUST include the (possibly negotiated) Traffic | If the negotiation flag was set in the label request message, the | |||
Parameters and Weight in the Label Mapping message. | egress LSR MUST include the (possibly negotiated) Traffic Parameters | |||
and Weight in the Label Mapping message. | ||||
The Traffic Parameters and the Weight in a Label Mapping message MUST | ||||
be forwarded unchanged. | ||||
CR-LDP Specification - 17 - Exp. August 1999 | The Traffic Parameters and the Weight in a Label Mapping message | |||
MUST be forwarded unchanged. | ||||
An LSR SHOULD adjust the resources that it reserved for a CRLSP when | An LSR SHOULD adjust the resources that it reserved for a CRLSP when | |||
it receives a Label Mapping Message if the Traffic Parameters differ | it receives a Label Mapping Message if the Traffic Parameters differ | |||
from those in the corresponding Label Request Message. | from those in the corresponding Label Request Message. | |||
4.3.2.3 Notification Message | 4.3.2.3 Notification Message | |||
If an LSR receives a Notification Message for a CRLSP, it SHOULD | If an LSR receives a Notification Message for a CRLSP, it SHOULD | |||
release any resources that it possibly had reserved for the CRLSP. | release any resources that it possibly had reserved for the CRLSP. | |||
In addition, on receiving a Notification Message from a Downstream | In addition, on receiving a Notification Message from a Downstream | |||
LSR that is associated with a Label Request from an upstream LSR, the | LSR that is associated with a Label Request from an upstream LSR, | |||
local LSR MUST propagate the Notification message using the | the local LSR MUST propagate the Notification message using the | |||
procedures in [LDP]. | procedures in [1]. | |||
4.4 Preemption TLV | 4.4 Preemption TLV | |||
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 | ||||
on gradually in an operational network by increasing or decerasing | ||||
the priority starting at the middle of the range. | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| Preemption-TLV (0x0820) | Length | | |0|0| Preemption-TLV (0x0820) | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SetPrio | HoldPrio | Reserved | | | SetPrio | HoldPrio | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 16 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
Type | Type | |||
A fourteen-bit field carrying the value of the Preemption-TLV | A fourteen-bit field carrying the value of the Preemption-TLV | |||
type which is 0x810. | type which is 0x810. | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
Reserved | Reserved | |||
Zero on transmission. Ignored on receipt. | Zero on transmission. Ignored on receipt. | |||
SetPrio | SetPrio | |||
A SetupPriority of value zero (0) is the priority assigned to the | A SetupPriority of value zero (0) is the priority assigned to | |||
most important path. It is referred to as the highest priority. | the most important path. It is referred to as the highest | |||
Seven (7) is the priority for the least important path. The higher | priority. Seven (7) is the priority for the least important | |||
the setup priority, the more paths CR-LDP can bump to set up the | path. The higher the setup priority, the more paths CR-LDP can | |||
path. | bump to set up the path. The default value should be 4. | |||
HoldPrio | HoldPrio | |||
A HoldingPriority of value zero (0) is the priority assigned to | A HoldingPriority of value zero (0) is the priority assigned to | |||
the most important path. It is referred to as the highest | the most important path. It is referred to as the highest | |||
priority. Seven (7) is the priority for the least important path. | priority. Seven (7) is the priority for the least important | |||
path. The default value should be 4. | ||||
CR-LDP Specification - 18 - Exp. August 1999 | The higher the holding priority, the less likely it is for CR- | |||
LDP to reallocate its bandwidth to a new path. | ||||
The higher the holding priority, the less likely it is for CR-LDP | ||||
to reallocate its bandwidth to a new path. | ||||
4.5 LSPID TLV | 4.5 LSPID TLV | |||
LSPID is a unique identifier of a CRLSP within an MPLS network. | LSPID is a unique identifier of a CRLSP within an MPLS network. | |||
The LSPID is composed of the ingress LSR Router ID and a Locally | The LSPID is composed of the ingress LSR Router ID and a Locally | |||
unique CRLSP ID to that LSR. | unique CRLSP ID to that LSR. | |||
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 indicator | ||||
flag_ indicates explicitly the action that should be taken if the | ||||
LSP already exists on the LSR receiving the message. | ||||
The procedure for the code point _modify_ is defined in section 2.1. | ||||
of [10]. The 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| LSPID-TLV (0x0821) | Length | | |0|0| LSPID-TLV (0x0821) | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Reserved | Local CRLSP ID | | | Reserved |ActFlg | Local CRLSP ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Ingress LSR Router ID | | | Ingress LSR Router ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 17 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
Type | Type | |||
A fourteen-bit field carrying the value of the LSPID-TLV | A fourteen-bit field carrying the value of the LSPID-TLV type | |||
type which is 0x821. | which is 0x821. | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
ActFlg | ||||
Action Indicator Flag: A 4-bit field that indicates explicitly | ||||
the action that should be taken if the LSP already exists on | ||||
the LSR receiving the message. A set of indicator code points | ||||
is proposed as follows: | ||||
0001: modify | ||||
Reserved | Reserved | |||
Zero on transmission. Ignored on receipt. | Zero on transmission. Ignored on receipt. | |||
Local CRLSP ID | Local CRLSP ID | |||
The Local LSP ID is an identifier of the CRLSP locally unique | The Local LSP ID is an identifier of the CRLSP locally unique | |||
within the Ingress LSR originating the CRLDP. | within the Ingress LSR originating the CRLDP. | |||
Ingress LSR Router ID | Ingress LSR Router ID | |||
A 4 byte field indicating the Ingress LSR ID. | "An LSR may use any of its own IPv4 in this field" | |||
4.6 Resource Class (Color) TLV | 4.6 Resource Class (Color) TLV | |||
The Resource Class as defined in [TER] is used to specify which links | The Resource Class as defined in [4] is used to specify which links | |||
are acceptable by this CRLSP. This information allows for the | are acceptable by this CRLSP. This information allows for the | |||
network's topology to be pruned. | ||||
CR-LDP Specification - 19 - Exp. August 1999 | ||||
networks 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| ResCls-TLV (0x0822) | Length | | |0|0| ResCls-TLV (0x0822) | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| RsCls | | | RsCls | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | ||||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
Type | Type | |||
A fourteen-bit field carrying the value of the ResCls-TLV | A fourteen-bit field carrying the value of the ResCls-TLV type | |||
type which is 0x822. | which is 0x822. | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
RsCls | RsCls | |||
The Resource Class bit mask indicating which of the | The Resource Class bit mask indicating which of the 32 | |||
32 "administrative groups" or "colors" of links | _administrative groups_ or _colors_ of links the CRLSP can | |||
the CRLSP can traverse. | traverse. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 18 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
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 a | which have an IP address, which lies within this prefix. Note that | |||
prefix length of 32 indicates a single IPv4 node. | a prefix length of 32 indicates a single IPv4 node. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| 0x801 | Length | | |0|0| 0x801 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L| Reserved | PreLen | | |L| Reserved | PreLen | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IPv4 Address (4 bytes) | | | IPv4 Address (4 bytes) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | ||||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
CR-LDP Specification - 20 - Exp. August 1999 | ||||
Type | Type | |||
IPv4 Address 0x801 | IPv4 Address 0x801 | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
L Bit | L Bit | |||
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 | |||
A four byte field indicating the IP Address. | A four-byte field indicating the IP Address. | |||
4.7.2. ER-Hop 2: The IPv6 address | 4.7.2. ER-Hop 2: The IPv6 address | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| 0x802 | Length | | |0|0| 0x802 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L| Reserved | PreLen | | |L| Reserved | PreLen | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IPV6 address | | | IPV6 address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IPV6 address (continued) | | | IPV6 address (continued) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IPV6 address (continued) | | | IPV6 address (continued) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IPV6 address (continued) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
U bit | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 19 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | | IPV6 address (continued) | | |||
Forward unknown TLV bit. As defined in [LDP]. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Type | Type | |||
0x802 IPv6 address | 0x802 IPv6 address | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
L Bit | L Bit | |||
Set to indicate Loose hop. | Set to indicate Loose hop. | |||
CR-LDP Specification - 21 - Exp. August 1999 | ||||
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-128 | Prefix Length 1-128 | |||
IPv6 address | IPv6 address | |||
A 128-bit unicast host address. | A 128-bit unicast host address. | |||
4.7.3. ER-Hop 32: The autonomous system number | 4.7.3. ER-Hop 3: The autonomous system number | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| 0x803 | Length | | |0|0| 0x803 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L| Reserved | AS Number | | |L| Reserved | AS Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | ||||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
Type | Type | |||
AS Number 0x803 | AS Number 0x803 | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
L Bit | L Bit | |||
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. | |||
AS Number | AS Number | |||
Autonomous System number | Autonomous System number | |||
4.7.4. ER-Hop 4: LSPID | 4.7.4. ER-Hop 4: LSPID | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 20 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
The LSPID is used to identify the tunnel ingress point as the next | The LSPID is used to identify the tunnel ingress point as the next | |||
hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an | hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an | |||
already established CR-LSP. It also allows for splicing the CR-LSP | already established CR-LSP. It also allows for splicing the CR-LSP | |||
being established with an existing CR-LSP. | ||||
CR-LDP Specification - 22 - Exp. August 1999 | If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may | |||
splice the CR-LSP of the incoming Label Request to the CR-LSP that | ||||
currently exists with this LSPID. This is useful, for example, at | ||||
the point at which a Label Request used for local repair arrives at | ||||
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 | ||||
keep the entire remaining ER-TLV at each LSR that is at either | ||||
(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 | ||||
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 | ||||
end to be able to recognize that the same LSP is being identified. | ||||
being established with an existing CR-LSP. | If the LSPID Hop is not the last hop in an ER-TLV, the LSR must | |||
forward the remaining ER-TLV in a Label Request message, using the | ||||
CR-LSP specified by the LSPID, to the LSR that is the CR-LSP's | ||||
egress. That LSR will continue processing of the CR-LSP Label | ||||
Request Message. The result is a tunneled, or stacked, CR-LSP. | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| 0x804 | Length | | |0|0| 0x804 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L| Reserved | Local LSPID | | |L| Reserved | Local LSPID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Ingress LSR Router ID | | | Ingress LSR Router ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | ||||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
Type | Type | |||
LSPID 0x804 | LSPID 0x804 | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
L Bit | L Bit | |||
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. | |||
Local LSPID | Local LSPID | |||
A 2 byte field indicating the LSPID which is unique | A 2 byte field indicating the LSPID which is unique with | |||
with reference to the its Ingress LSR. | reference to its Ingress LSR. | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 21 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
Ingress LSR Router ID | Ingress LSR Router ID | |||
A 4 byte field indicating the Ingress LSR ID. | "An LSR may use any of its own IPv4 addresses in this field" | |||
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 a explicit route TLV must | A Label Request Message containing a explicit route TLV must | |||
determine the next hop for this path. Selection of this next hop may | determine the next hop for this path. Selection of this next hop | |||
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. | |||
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 | |||
effort attempt to determine a loop-free path. Note that such best | effort attempt to determine a loop-free path. Note that such best | |||
CR-LDP Specification - 23 - Exp. August 1999 | ||||
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 following | To determine the next hop for the path, a node performs the | |||
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 first | evaluate the first ER-Hop. If the L bit is not set in the | |||
ER-Hop and if the node is not part of the abstract node described | first ER-Hop and if the node is not part of the abstract node | |||
by the first ER-Hop, it has received the message in error, and | described by the first ER-Hop, it has received the message in | |||
should return a "Bad initial ER-Hop" error. If the L bit is set | error, and should return a _Bad initial ER-Hop_ error. If the | |||
and the local node is not part of the abstract node described by | L bit is set and the local node is not part of the abstract | |||
the first ER-Hop, the node selects a next hop that is along the | node described by the first ER-Hop, the node selects a next | |||
path to the abstract node described by the first ER-Hop. If there | hop that is along the path to the abstract node described by | |||
is no first ER-Hop, the message is also in error and the system | the first ER-Hop. If there is no first ER-Hop, the message is | |||
should return a "Bad Explicit Routing TLV" error. | also in error and the system should return a _Bad Explicit | |||
Routing TLV_ error. | ||||
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 the | explicit route. The explicit route TLV should be removed from | |||
Label Request Message. This node may or may not be the end of the | the Label Request Message. This node may or may not be the | |||
LSP. Processing continues with section 4.8.2, where a new | end of the LSP. Processing continues with section 4.8.2, | |||
explicit route TLV may be added to the Label Request Message. | where a new explicit route TLV may be added to the Label | |||
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 the | continues processing with step 2, above. Note that this makes | |||
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 abstract | selects a particular next hop which is a member of the | |||
node. The node then deletes the first ER-Hop and continues | abstract node. The node then deletes the first ER-Hop and | |||
processing with section 4.8.2. | continues processing with section 4.8.2. | |||
5) Next, the node selects a next hop within the abstract node of | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 22 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
the first ER-Hop that is along the path to the abstract node of | ||||
the second ER-Hop. If no such path exists then there are two | ||||
cases: | ||||
5a) If the second ER-Hop is a strict ER-Hop, then there is an | 5. Next, the node selects a next hop within the abstract node of | |||
error and the node should return a "Bad strict node" error. | the first ER-Hop that is along the path to the abstract node | |||
of the second ER-Hop. If no such path exists then there are | ||||
two cases: | ||||
5b) Otherwise, if the second ER-Hop is a loose ER-Hop, then the | 5.a If the second ER-Hop is a strict ER-Hop, then there is | |||
node selects any next hop that is along the path to the next | an error and the node should return a _Bad strict node_ | |||
abstract node. If no path exists within the MPLS domain, then | ||||
there is an error, and the node should return a "Bad loose node" | ||||
error. | error. | |||
6) Finally, the node replaces the first ER-Hop with any ER-Hop | 5.b Otherwise, if the second ER-Hop is a loose ER-Hop, then | |||
that denotes an abstract node containing the next hop. This is | the node selects any next hop that is along the path to the | |||
necessary so that when the explicit route is received by the next | next abstract node. If no path exists within the MPLS | |||
hop, it will be accepted. | domain, then there is an error, and the node should return a | |||
_Bad loose node_ error. | ||||
CR-LDP Specification - 24 - Exp. August 1999 | 6. Finally, the node replaces the first ER-Hop with any ER-Hop | |||
that denotes an abstract node containing the next hop. This | ||||
is 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 explicit | If, as part of executing the algorithm in section 4.8.1, the | |||
route TLV is removed, the node may add a new explicit route TLV. | explicit route TLV is removed, the node may add a new explicit route | |||
TLV. | ||||
Otherwise, if the node is a member of the abstract node for the first | Otherwise, if the node is a member of the abstract node for the | |||
ER-Hop, then a series of ER-Hops may be inserted before the first | first ER-Hop, then a series of ER-Hops may be inserted before the | |||
ER-Hop or may replace the first ER-Hop. Each ER-Hop in this series | first ER-Hop or may replace the first ER-Hop. Each ER-Hop in this | |||
must denote an abstract node that is a subset of the current abstract | series must denote an abstract node that is a subset of the current | |||
node. | abstract node. | |||
Alternately, if the first ER-Hop is a loose ER-Hop, an arbitrary | Alternately, if the first ER-Hop is a loose ER-Hop, an arbitrary | |||
series of ER-Hops may be inserted prior to the first ER-Hop. | series of ER-Hops may be inserted prior to the first ER-Hop. | |||
4.9 Route Pinning TLV | 4.9 Route Pinning TLV | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| 0x823 | Length | | |0|0| 0x823 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|P| Reserved | | |P| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
U bit | ||||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
Type | Type | |||
Pinning-TLV type 0x823 | Pinning-TLV type 0x823 | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 23 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
P Bit | P Bit | |||
The P bit is set to 1 to indicate that route pinning is requested. | The P bit is set to 1 to indicate that route pinning is | |||
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 | |||
Reserved | Reserved | |||
Zero on transmission. Ignored on receipt. | Zero on transmission. Ignored on receipt. | |||
4.10 CRLSP FEC Element | 4.10 CRLSP FEC Element | |||
CR-LDP Specification - 25 - Exp. August 1999 | ||||
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. The CRLDP FEC Element is an opaque FEC. | LSPs. This new FEC element does not preclude the use of other FECs | |||
elements (Type=0x01, 0x02, 0x03) defined in the LDP spec in CR-LDP | ||||
messages. The CRLDP FEC Element is an opaque FEC to be used only in | ||||
Messages of CR-LSPs. | ||||
FEC Element Type Value | FEC Element Type Value | |||
type name | Type name | |||
CRLSP 0x04 No value; i.e., 0 value octets; | CRLSP 0x04 No value; i.e., 0 value octets; | |||
see below. | ||||
CRLSP FEC Element | ||||
To be used only in Messages of CR-LSPs. | ||||
The CR-LSP FEC TLV encoding is as follows: | The CR-LSP FEC TLV encoding 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|U|F| FEC(0x0100) | Length | | |0|0| FEC(0x0100) | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| CR-LSP (4) | Reserved | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| CR-LSP (4) | | ||||
U bit | +-+-+-+-+-+-+-+-+ | |||
Unknown TLV bit. As defined in [LDP]. | ||||
F bit | ||||
Forward unknown TLV bit. As defined in [LDP]. | ||||
Type | Type | |||
FEC TLV type 0x0100 | FEC TLV type 0x0100 | |||
Length | Length | |||
Specifies the length of the value field in bytes. | Specifies the length of the value field in bytes. | |||
CR-LSP FEC Element Type | CR-LSP FEC Element Type | |||
0x04 | 0x04 | |||
Reserved | ||||
Zero on transmission. Ignored on receipt. | ||||
4.11 Error subcodes | 4.11 Error subcodes | |||
In the processing described above, certain errors need to be reported | In the processing described above, certain errors need to be | |||
as part of the Notification Message. This section defines the status | reported as part of the Notification Message. This section defines | |||
codes for the errors described in this specification. | the status codes for the errors described in this specification. | |||
CR-LDP Specification - 26 - Exp. August 1999 | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 24 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
Status Code Type | Status Code Type | |||
-------------------------------------- ---------- | -------------------------------------- ---------- | |||
Bad Explicit Routing TLV Error 0x04000001 | Bad Explicit Routing TLV Error 0x44000001 | |||
Bad Strict Node Error 0x04000002 | Bad Strict Node Error 0x44000002 | |||
Bad Loose Node Error 0x04000003 | Bad Loose Node Error 0x44000003 | |||
Bad Initial ER-Hop Error 0x04000004 | Bad Initial ER-Hop Error 0x44000004 | |||
Resource Unavailable 0x04000005 | Resource Unavailable 0x44000005 | |||
Traffic Parameters Unavailable 0x04000006 | Traffic Parameters Unavailable 0x44000006 | |||
Setup abort 0x04000007 | Setup abort (Label Request Aborted in [1]) 0x04000015 | |||
Modify request not supported 0x44000008 | ||||
5. Security | 5. Security | |||
Pre-emption has to be controlled by the MPLS domain. | Pre-emption has to be controlled by the MPLS domain. | |||
Resource reservation requires the LSRs to have an LSP admission | Resource reservation requires the LSRs to have an LSP admission | |||
control function. | control function. | |||
Normal routing can be bypassed by Traffic Engineered LSPs. | Traffic Engineered LSPs can bypass normal routing. | |||
6. Acknowledgments | 6. Acknowledgments | |||
The messages used to signal the CRLSP setup are based on the work | The messages used to signal the CRLSP setup are based on the work | |||
done by the [LDP] team. The Explicit Route object and procedures used | done by the [1] team. The Explicit Route object and procedures used | |||
in this specification are based on [ER]. | in this specification are based on [8]. | |||
The authors would also like to acknowledge the careful review and | The authors would also like to acknowledge the careful review and | |||
comments of Ken Hayward, Greg Wright, Geetha Brown, Brian Williams, | comments of Ken Hayward, Greg Wright, Geetha Brown, Brian Williams, | |||
Paul Beaubien, Matthew Yuen, Liam Casey, and Ankur Anand. | Paul Beaubien, Matthew Yuen, Liam Casey, and Ankur Anand. | |||
7. References | 7. Intellectual Property Consideration | |||
[LDP] Andersson et al, "Label Distribution Protocol Specification" | Nortel Networks may seek patent or other intellectual property | |||
work in progress (draft-ietf-mpls-ldp-03), Feb. 1999. | protection for some or all of the technologies disclosed in this | |||
document. If any standards arising from this document are or become | ||||
protected by one or more patents assigned to Nortel Networks, Nortel | ||||
Networks is prepared to make a license available to any qualified | ||||
applicant upon reasonable and non-discriminatory terms and | ||||
conditions. Any such licenses will be subject to negotiations | ||||
outside of the IETF. | ||||
[ARCH] Rosen et al, "Multiprotocol Label Switching Architecture", | 8. References | |||
work in progress (draft-ietf-mpls-arch-04), Feb. 1999. | ||||
[FRAME] Callon et al, "Framework for Multiprotocol Label Switching", | 1 Andersson et al, "Label Distribution Protocol Specification" | |||
work in progress (draft-ietf-mpls-framework-02), November | work in progress (draft-ietf-mpls-ldp-05), June 1999. | |||
1997. | ||||
[TER] Awduche et al, "Requirements for Traffic Engineering Over | 2 Callon et al, "Framework for Multiprotocol Label Switching", | |||
MPLS", work in progress (draft-ietf-mpls-traffic-eng-00), | work in progress (draft-ietf-mpls-framework-04), July 1999. | |||
August 1998. | ||||
[ER] Guerin et al, "Setting up Reservations on Explicit Paths | 3 Rosen et al, "Multiprotocol Label Switching Architecture", | |||
using RSVP", work in progress (draft-guerin-expl-path-rsvp- | work in progress (draft-ietf-mpls-arch-04), April 1999. | |||
01) | ||||
November 1997. | ||||
CR-LDP Specification - 27 - Exp. August 1999 | Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 25 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
[VPN1] Heinanen et al, "MPLS Mappings of Generic VPN Mechanisms", | 4 Awduche et al, "Requirements for Traffic Engineering Over | |||
MPLS", work in progress (draft-ietf-mpls-traffic-eng-01), | ||||
June 1999. | ||||
5 Heinanen et al, "MPLS Mappings of Generic VPN Mechanisms", | ||||
work in progress (draft-heinanen-generic-vpn-mpls-00), | work in progress (draft-heinanen-generic-vpn-mpls-00), | |||
August 1998. | August 1998. | |||
[VPN2] Jamieson et al, "MPLS VPN Architecture" work in progress | 6 Jamieson et al, "MPLS VPN Architecture" work in progress | |||
(draft-jamieson-mpls-vpn-00), August 1998. | (draft-jamieson-mpls-vpn-00), August 1998. | |||
[VPN3] T. Li, "CPE based VPNs using MPLS", work in progress (draft- | 7 T. Li, "CPE based VPNs using MPLS", work in progress (draft- | |||
li-mpls-vpn-00.txt), October 1998. | li-mpls-vpn-00.txt), October 1998. | |||
[LDP-STATE] L. Wu, et. al., "LDP State Machine" work in progress | 8 Guerin et al, "Setting up Reservations on Explicit Paths using | |||
RSVP", work in progress (draft-guerin-expl-path-rsvp-01) November | ||||
1997. | ||||
9 L. Wu, et. al., "LDP State Machine" work in progress | ||||
(draft-ietf-mpls-ldp-state-00), Feb 1999. | (draft-ietf-mpls-ldp-state-00), Feb 1999. | |||
CR-LDP Specification - 28 - Exp. August 1999 | 10 J. Ash, et. al., _LSP Modification Using CR-LDP_ work in progress | |||
(draft-ash-crlsp-modify-00.txt), July 1999. | ||||
8. Author Information | 9. Author's Addresses | |||
Osama S. Aboul-Magd Loa Andersson | Osama S. Aboul-Magd Loa Andersson | |||
Nortel Networks Director Bay Architecture Lab,EMEA | Nortel Networks Nortel Networks | |||
P O Box 3511 Station C Kungsgatan 34, PO Box 1788 | P O Box 3511 Station C Kungsgatan 34, PO Box 1788 | |||
Ottawa, ON K1Y 4H7 111 97 Stockholm, Sweden | Ottawa, ON K1Y 4H7 111 97 Stockholm, Sweden | |||
Canada phone: +46 8 441 78 34 | Canada Phone: +46 8 441 78 34 | |||
phone: +1 613 763-5827 mobile +46 70 522 78 34 | Phone: +1 613 763-5827 Mobile +46 70 522 78 34 | |||
osama@NortelNetworks.com loa_andersson@baynetworks.com | Osama@nortelnetworks.com Loa_andersson@beynetworks.com | |||
Peter Ashwood-Smith Ross Callon | Peter Ashwood-Smith Ross Callon | |||
Nortel Networks IronBridge Networks | Nortel Networks IronBridge Networks | |||
P O Box 3511 Station C 55 Hayden Avenue, | P O Box 3511 Station C 55 Hayden Avenue, | |||
Ottawa, ON K1Y 4H7 Lexington, MA 02173 | Ottawa, ON K1Y 4H7 Lexington, MA 02173 | |||
Canada Phone: +1-781-402-8017 | Canada Phone: +1-781-402-8017 | |||
phone: +1 613 763-4534 rcallon@ironbridgenetworks.com | Phone: +1 613 763-4534 Rcallon@ironbridgenetworks.com | |||
petera@NortelNetworks.com | Petera@nortelnetworks.com | |||
Ram Dantu Paul Doolan | Ram Dantu Paul Doolan | |||
Alcatel USA Inc. Ennovate Networks | Alcatel USA Inc. Ennovate Networks | |||
IP Competence Center 330 Codman Hill Rd | IP Competence Center 330 Codman Hill Rd | |||
1201 E. Campbell Road.,446-315 Marlborough MA 01719 | 1201 E. Campbell Road.,446-315 Marlborough MA 01719 | |||
Richadson, TX USA., 75081-2206 Phone: 978-263-2002 | Richadson, TX USA., 75081-2206 Phone: 978-263-2002 | |||
Phone: 972 996 2938 pdoolan@ennovatenetworks.com | Phone: 972 996 2938 Pdoolan@ennovatenetworks.com | |||
Fax: 972 996 5902 | Fax: 972 996 5902 | |||
ram.dantu@aud.alcatel.com | Ram.dantu@aud.alcatel.com | |||
Jamoussi, et. al. draft-ietf-mpls-crldp-02.txt 26 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
Nancy Feldman Andre Fredette | Nancy Feldman Andre Fredette | |||
IBM Corp. Nortel Networks | IBM Corp. Nortel Networks | |||
17 Skyline Drive 3 Federal Street | 17 Skyline Drive 3 Federal Street | |||
Hawthorne NY 10532 Billerica, MA 01821 | Hawthorne NY 10532 Billerica, MA 01821 | |||
Phone: 914-784-3254 fredette@baynetworks.com | Phone: 914-784-3254 978-288-8524 | |||
nkf@us.ibm.com | Nkf@us.ibm.com Fredette@baynetworks.com | |||
Eric Gray Joel M. Halpern | Eric Gray Joel M. Halpern | |||
Lucent Technologies, Inc Newbridge Networks Inc. | Lucent Technologies, Inc Institutional Venture Partners | |||
1600 Osgood St. 593 Herndon Parkway | 1600 Osgood St. 650-926-5633 | |||
North Andover, MA 01847 Herndon, VA 20170 | North Andover, MA 01847 joel@mcquillan.com | |||
Phone: 603-659-3386 phone: 1-703-736-5954 | Phone: 603-659-3386 | |||
ewgray@lucent.com jhalpern@newbridge.com | Ewgray@lucent.com | |||
Juha Heinanen Fiffi Hellstrand | Juha Heinanen Fiffi Hellstrand | |||
Telia Finland, Inc. Ericsson Telecom AB | Telia Finland, Inc. Ericsson Telecom AB | |||
Myyrmaentie 2 S-126 25 STOCKHOLM | Myyrmaentie 2 S-126 25 STOCKHOLM | |||
01600 VANTAA Sweden | 01600 VANTAA Sweden | |||
Finland Tel: +46 8 719 4933 | Finland Tel: +46 8 719 4933 | |||
Tel: +358 41 500 4808 etxfiff@etxb.ericsson.se | Tel: +358 41 500 4808 etxfiff@etxb.ericsson.se | |||
jh@telia.fi | Jh@telia.fi | |||
CR-LDP Specification - 29 - Exp. August 1999 | ||||
Bilel Jamoussi Timothy E. Kilty | Bilel Jamoussi Timothy E. Kilty | |||
Nortel Networks Northchurch Communications | Nortel Networks Corp. Northchurch Communications | |||
P O Box 3511 Station C 5 Corporate Drive, | 3 Federal Street 5 Corporate Drive, | |||
Ottawa, ON K1Y 4H7 Andover, MA 018110 | Billerica, MA 01821 Andover, MA 018110 | |||
Canada phone: 978 691-4656 | USA phone: 978 691-4656 | |||
phone: +1 613 765-4814 tkilty@northc.com | Phone: +1 978 288-4506 tkilty@northc.com | |||
jamoussi@NortelNetworks.com | Jamoussi@nortelnetworks.com | |||
Andrew G. Malis Muckai K Girish | Andrew G. Malis Muckai K Girish | |||
Ascend Communications, Inc. SBC Technology Resources, Inc. | Ascend Communications, Inc. SBC Technology Resources, | |||
1 Robbins Road 4698 Willow Road | 1 Robbins Road 4698 Willow Road | |||
Westford, MA 01886 Pleasanton, CA 94588 | Westford, MA 01886 Pleasanton, CA 94588 | |||
phone: 978 952-7414 Phone: (925) 598-1263 | Phone: 978 952-7414 Phone: (925) 598-1263 | |||
fax: 978 392-2074 Fax: (925) 598-1321 | fax: 978 392-2074 Fax: (925) 598-1321 | |||
malis@ascend.com mgirish@tri.sbc.com | Malis@ascend.com mgirish@tri.sbc.com | |||
Kenneth Sundell Pasi Vaananen | Kenneth Sundell Pasi Vaananen | |||
Ericsson Nokia Telecommunications | Nortel Networks Nokia Telecommunications | |||
SE-126 25 Stockholm 3 Burlington Woods Drive, Suite 250 | Architecture Lab, EMEA 3 Burlington Woods Drive, | |||
Sweden Burlington, MA 01803 | Kungsgatan 34, PO Box 1788 Burlington, MA 01803 | |||
kenneth.sundell@etx.ericsson.se Phone: +1-781-238-4981 | 111 97 Stockholm, Sweden Phone: +1-781-238-4981 | |||
pasi.vaananen@ntc.nokia.com | phone: +46 8 441-7838, Pasi.vaananen@ntc.nokia.com | |||
mobile +46 70 665-7838 | ||||
ksundell@nortelnetworks.com | ||||
Tom Worster Liwen Wu | Jamoussi, et. al. draft-ietf-mpls-cr-ldp-02.txt 27 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
General DataComm, Inc. Alcatel U.S.A | ||||
5 Mount Royal Ave. 44983 Knoll Square | ||||
Marlboro MA 01752 Ashburn, Va. 20147 | ||||
tom.worster@gdc.com USA | ||||
Phone: (703) 724-2619 | ||||
FAX: (703) 724-2005 | ||||
liwen.wu@adn.alcatel.com | ||||
CR-LDP Specification - 30 - Exp. August 1999 | Tom worster Liwen Wu | |||
Nokia Alcatel U.S.A | ||||
3 Burlington Woods Dr. 44983 Knoll Square | ||||
Suite 250 Ashburn, Va. 20147 | ||||
Burlington MA 01803 USA Phone: (703) 724-2619 | ||||
+1 617 247 2624 FAX: (703) 724-2005 | ||||
tom.worster@nokia.com Liwen.wu@and.alcatel.com | ||||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-02.txt 28 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
Appendix A: CRLSP Establishment Examples | Appendix A: CRLSP 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 | |||
CRLSP. In this example, each abstract node is represented by a | CRLSP. In this example, a specific node represents each abstract | |||
specific 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 | |||
LSRs and two core LSRs as follows: | edge LSRs and two core LSRs as follows: | |||
a b c | a b c | |||
LSR1------LSR2------LSR3------LSR4 | LSR1------LSR2------LSR3------LSR4 | |||
LSR1 generates a Label Request Message as described in Section 3.1 of | LSR1 generates a Label Request Message as described in Section 3.1 | |||
this draft and sends it to LSR2. This message includes the CR-TLV. | of this draft and sends it to LSR2. This message includes the CR- | |||
TLV. | ||||
The ER-TLV is composed by a vector of three ER-Hop TLVs <a, b, c>. | ||||
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 identifies a | ||||
specific node as opposed to a group of nodes. | ||||
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 | ||||
prefix) with a prefix length of 32. Hence, each ER-Hop TLV | ||||
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 first hop <a> is part of the abstract node LSR2. Therefore, | 1) The first hop <a> is part of the abstract node LSR2. | |||
the first step passes the test. Go to step 2. | Therefore, the first step passes the test. Go 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 second | 3) LSR2 is not part of the abstract node described by the | |||
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 selects a | abstract node described by the second ER-Hop <b>. LSR2 selects | |||
next hop (LSR3) which is the abstract node. LSR2 deletes the first | a next hop (LSR3) which is the abstract node. LSR2 deletes the | |||
ER-Hop <a> from the ER-TLV which now becomes <b , c>. Go to | first ER-Hop <a> from the ER-TLV which now becomes <b , c>. Go | |||
Section 4.8.2. | to 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 | TLV. | |||
ER-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 | Therefore, processing section 4.8.2 does not result in the insertion | |||
insertion of new ER-Hops. The selection of the next hop has been | 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 | ||||
CR-LDP Specification - 31 - Exp. August 1999 | Jamoussi, et. al. draft-ietf-mpls-cr-ldp-02.txt 29 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
already done is step 4 of Section 4.8.1 and the processing of the | completed at LSR2. In this case, the Label Request Message including | |||
ER-TLV is completed at LSR2. In this case, the Label Request | the ER-TLV <b, c> is progressed by LSR2 to LSR3. | |||
Message including 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 first hop <c> is part of the abstract node LSR4. Therefore, | 1) The first hop <c> is part of the abstract node LSR4. | |||
the first step passes the test. Go to step 2. | Therefore, the first step passes the test. Go to step 2. | |||
2) There is no second ER-Hop, this indicates the end of the CRLSP. | 2) There is no second ER-Hop, this indicates the end of the | |||
The ER-TLV is removed from the Label Request Message. Processing | CRLSP. The ER-TLV is removed from the Label Request Message. | |||
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 | Therefore, processing section 4.8.2 does not result in the insertion | |||
insertion of new ER-Hops. This indicates the end of the CRLSP and | of new ER-Hops. This indicates the end of the CRLSP and the | |||
the processing of the ER-TLV is completed at LSR4. | processing of the ER-TLV is completed at LSR4. | |||
At LSR4, processing of Section 3.2 is invoked. The first condition is | At LSR4, processing of Section 3.2 is invoked. The first condition | |||
satisfied (LSR4 is the egress end of the CRLSP and upstream mapping | is satisfied (LSR4 is the egress end of the CRLSP and upstream | |||
has been requested). Therefore, a Label Mapping Message is generated | mapping has been requested). Therefore, a Label Mapping Message is | |||
by LSR4 and sent to LSR3. | generated by LSR4 and sent to LSR3. | |||
At LSR3, the processing of Section 3.2 is invoked. The second | At LSR3, the processing of Section 3.2 is invoked. The second | |||
condition is satisfied (LSR3 received a mapping from its downstream | condition is satisfied (LSR3 received a mapping from its downstream | |||
next hop LSR4 for a CRLSP for which an upstream request is still | next hop LSR4 for a CRLSP for which an upstream request is still | |||
pending). Therefore, a Label Mapping Message is generated by LSR3 and | pending). Therefore, a Label Mapping Message is generated by LSR3 | |||
sent to LSR2. | and sent to LSR2. | |||
At LSR2, a similar processing to LSR 3 takes place and a Label | At LSR2, a similar processing to LSR 3 takes place and a Label | |||
Mapping Message is sent back to LSR1 which completes the end-to-end | Mapping Message is sent back to LSR1 which completes the end-to-end | |||
CRLSP setup. | CRLSP setup. | |||
A.2. Node Groups and Specific Nodes Example | A.2. Node Groups and Specific Nodes Example | |||
A request at an ingress LSR to setup a CRLSP might originate from a | A request at ingress LSR to setup a CRLSP might originate from a | |||
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 or | The ingress LSR uses information provided by the management system | |||
the application and possibly also information from the routing | or the application and possibly also information from the routing | |||
database to calculated the explicit route and to create the Label | database to calculate the explicit route and to create the Label | |||
Request Message. | Request Message. | |||
CR-LDP Specification - 32 - Exp. August 1999 | ||||
The Label request message carries together with other necessary | The Label request message carries together with other necessary | |||
information a ER-TLV defining the explicitly routed path. In our | information a ER-TLV defining the explicitly routed path. In our | |||
example the list of hops in the ER-Hop TLV is supposed to contain an | example the list of hops in the ER-Hop TLV is supposed to contain an | |||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-02.txt 30 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
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 first | 1. An ER-Hop TLV that specifies a group of LSR valid for the | |||
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 2). | second abstract node representing a group of nodes (Group | |||
2). | ||||
4. An ER-Hop TLV that indicates the specific egress point for the | 4. An ER-Hop TLV that indicates the specific egress point for | |||
CRLSP (Node B). | the CRLSP (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 CRLSP works as follows: | The setup procedure for this CRLSP works as follows: | |||
1. The ingress node sends the Label Request Message to a node that | 1. The ingress node sends the Label Request Message to a node | |||
is a member the group of nodes indicated in the first ER-Hop TLV, | that is a member the group of nodes indicated in the first | |||
following normal routing for the specific node (A). | ER-Hop TLV, following normal routing for the specific node | |||
(A). | ||||
2. The node that receives the message identifies itself as part of | 2. The node that receives the message identifies itself as part | |||
the group indicated in the first ER-Hop TLV, and that it is not | of the group indicated in the first ER-Hop TLV, and that it | |||
the specific node (A) in the second. Further it realizes that the | is not the specific node (A) in the second. Further it | |||
specific node (A) is not one of its next hops. | realizes that the specific node (A) is not one of its next | |||
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 a node that is part of the group indicated in the first | Message to a node that is part of the group indicated in the | |||
ER-Hop TLV (Group 1), following normal routing for the specific | first ER-Hop TLV (Group 1), following normal routing for the | |||
node (A). | specific node (A). | |||
4. The node that receives the message identifies itself as part of | 4. The node that receives the message identifies itself as part | |||
the group indicated in the first ER-Hop TLV, and that it is not | of the group indicated in the first ER-Hop TLV, and that it | |||
the specific node (A) in the second ER-Hop TLV. Further it | is not the specific node (A) in the second ER-Hop TLV. | |||
realizes that the specific node (A) is one of its next hops. | Further it realizes that the specific node (A) is one of its | |||
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. | |||
CR-LDP Specification - 33 - Exp. August 1999 | Jamoussi, et. al. draft-ietf-mpls-cr-ldp-02.txt 31 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
7. It sends a Label Request Message to a node that is a member of | 7. It sends a Label Request Message to a node that is a member | |||
the group (Group 2) indicated in the ER-Hop TLV. | of the group (Group 2) indicated in the ER-Hop TLV. | |||
8. The node that receives the message identifies itself as part of | 8. The node that receives the message identifies itself as part | |||
the group indicated in the first ER-Hop TLV, further it realizes | of the group indicated in the first ER-Hop TLV, further it | |||
that the specific egress node (B) is one of its next hops. | realizes that the specific egress node (B) is one of its | |||
next 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 egress | |||
for the CRLSP, it returns a Label Mapping Message, that will | for the CRLSP, it returns a Label Mapping Message, that will | |||
traverse the same path as the Label Request Message in the | traverse the same path as the Label Request Message in the | |||
opposite direction. | opposite direction. | |||
CR-LDP Specification - 34 - Exp. August 1999 | Jamoussi, et. al. draft-ietf-mpls-cr-ldp-02.txt 32 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | |||
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 that | network nodes. The rules define the traffic conditioning actions | |||
are implemented at the edge and they include policing with pass, | that are implemented at the edge and they include policing with | |||
mark, and drop capabilities. The edge rules are expected to be | pass, mark, and drop capabilities. The edge rules are expected to | |||
defined by the mutual agreements between the service providers and | be defined by the mutual agreements between the service providers | |||
their customers and they will constitute an essential part of the | and their customers and they will constitute an essential part of | |||
SLA. Therefore edge rules are not included in the signaling protocol. | the SLA. Therefore edge rules are not included in the signaling | |||
protocol. | ||||
Packets treatment at a network node is usually referred to as the | Packet treatment at a network node is usually referred to as the | |||
local behavior. Local behavior could be specified in many ways. One | local behavior. Local behavior could be specified in many ways. One | |||
example for local behavior specification is the service frequency | example for local behavior specification is the service frequency | |||
introduced in section 4.3.2.1., together with the resource | introduced in section 4.3.2.1, together with the resource | |||
reservation rules implemented at the nodes. | reservation rules implemented at the nodes. | |||
Edge rules and local behaviors can be viewed as the main building | Edge rules and local behaviors can be viewed as the main building | |||
blocks for the end-to-end service construction. The following table | blocks for the end-to-end service construction. The following table | |||
illustrates the applicability of the building block approach for | illustrates the applicability of the building block approach for | |||
constructing different services including those defined for ATM. | constructing different services including those defined for ATM. | |||
Service PDR PBS CDR CBS EBS Service Conditioning | Service PDR PBS CDR CBS EBS Service Conditioning | |||
Examples Frequency Action | Examples Frequency Action | |||
DS S S =PDR =PBS 0 Frequent drop>PDR | DS S S =PDR =PBS 0 Frequent drop>PDR | |||
TS S S S S 0 Unspecified drop>PDR,PBS | TS S S S S 0 Unspecified drop>PDR,PBS | |||
mark>CDR,CBS | mark>CDR,CBS | |||
BE inf inf inf inf 0 Unspecified - | BE inf inf inf inf 0 Unspecified - | |||
FRS S S CIR ~B_C ~B_E Unspecified drop>PDR,PBS | FRS S S CIR ~B_C ~B_E Unspecified drop>PDR,PBS | |||
mark>CDR,CBS,EBS | mark>CDR,CBS,EBS | |||
skipping to change at page 35, line 5 | skipping to change at line 1680 | |||
ATM-VBR.3(rt) PCR CDVT SCR MBS 0 Frequent drop>PCR | ATM-VBR.3(rt) PCR CDVT SCR MBS 0 Frequent drop>PCR | |||
mark>SCR,MBS | mark>SCR,MBS | |||
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 | |||
CR-LDP Specification - 35 - Exp. August 1999 | ||||
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-02.txt 33 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
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. Datagrams | at a rate of PDR with minimum delay and delay requirements. | |||
in excess of PDR will be discarded. | Datagrams in excess of PDR will be discarded. | |||
The TS refers to a generic throughput sensitive service where the | The TS refers to a generic throughput sensitive service where the | |||
network commit to deliver with high probability user datagrams at a | network commits to deliver with high probability user datagrams at a | |||
rate of at least CDR. The user may transmit at a rate higher than CDR | rate of at least CDR. The user may transmit at a rate higher than | |||
but datagrams in excess of CDR would have a lower probability of | CDR but datagrams in excess of CDR would have a lower probability of | |||
being delivered. | being delivered. | |||
The BE is the best effort service and it implies that there are no | The BE is the best effort service and it implies that there are no | |||
expected service guarantees from the network. | expected service guarantees from the network. | |||
B.2. Establishing CR-LSP Supporting Real-Time Applications | B.2. Establishing CR-LSP Supporting Real-Time Applications | |||
In this scenario the customer needs to establish an LSP for | In this scenario the customer needs to establish an LSP for | |||
supporting real-time applications such voice and video. The Delay- | supporting real-time applications such voice and video. The Delay- | |||
sensitive (DS) service is requested in this case. | sensitive (DS) service is requested in this case. | |||
The first step is the specification of the traffic parameters in the | The first step is the specification of the traffic parameters in the | |||
signaling message. The two parameters of interest to the DS service | signaling message. The two parameters of interest to the DS service | |||
are the PDR and the PBS and their values are specified by the user | are the PDR and the PBS and the user based on his requirements | |||
based on his requirements. Since all the traffic parameters are | specifies their values. Since all the traffic parameters are | |||
included in the signaling message, appropriate values must be | included in the signaling message, appropriate values must be | |||
assigned to all of them. For DS service, the CDR and the CBS values | assigned to all of them. For DS service, the CDR and the CBS values | |||
are set equal to the PDR and the PBS respectively. An indication of | are set equal to the PDR and the PBS respectively. An indication of | |||
whether the parameter values are subject to negotiation is flagged. | whether the parameter values are subject to negotiation is flagged. | |||
The transport characteristics of the DS service requires that | The transport characteristics of the DS service require that | |||
Frequent frequency to be requested to reflect the real-time delay | Frequent frequency to be requested to reflect the real-time delay | |||
requirements of the service. | requirements of the service. | |||
In addition to the transport characteristics, both the network | In addition to the transport characteristics, both the network | |||
provider and the customer need to agree on the actions enforced at | provider and the customer need to agree on the actions enforced at | |||
the edge. The specification of those actions is expected to be a part | the edge. The specification of those actions is expected to be a | |||
of the service level agreement (SLA) negotiation and is not included | part of the service level agreement (SLA) negotiation and is not | |||
in the signaling protocol. For DS service, the edge action is to drop | included in the signaling protocol. For DS service, the edge action | |||
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 | |||
CR-LDP Specification - 36 - Exp. August 1999 | ||||
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 either the PDR, the PBS, or both. | then the LSR could negotiate down the PDR, the PBS, or both. | |||
The new parameters values are echoed back in the Label Mapping | ||||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-02.txt 34 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
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 is | In this example we assume that a throughput sensitive (TS) service | |||
requested. For resource allocation the user assigns values for PDR, | is requested. For resource allocation the user assigns values for | |||
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. | |||
Since the service is delay insensitive by definition, the | ||||
Unspecified frequency is signaled to indicate that the service | ||||
frequency is not an issue. | ||||
Since the service is delay insensitive by definition, the Unspecified | Similar to the previous example, the edge actions are not subject | |||
frequency is signaled to indicate that the service frequency is not | for signaling and are specified in the service level agreement | |||
an issue. | between the user and the network provider. | |||
Similar to the previous example, the edge actions are not subject for | ||||
signaling and are specified in the service level agreement between | ||||
the user and the network provider. | ||||
For TS service, the edge rules might include marking to indicate high | For TS service, the edge rules might include marking to indicate | |||
discard precedence values for all packets that exceed CDR and the | high discard precedence values for all packets that exceed CDR and | |||
CBS. The edge rules will also include dropping of packets that are do | the CBS. The edge rules will also include dropping of packets that | |||
not conform to either PDR and PBS. | are do not 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 parameters 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-02.txt 35 Internet Draft Constraint-Based LSP Setup using LDP August, 1999 | ||||
Full Copyright Statement | ||||
_Copyright c The Internet Society (date). All Rights Reserved. This | ||||
document and translations of it may be copied and furnished to | ||||
others, and derivative works that comment on or otherwise explain it | ||||
or assist in its implementation may be prepared, copied, published | ||||
and distributed, in whole or in part, without restriction of any | ||||
kind, provided that the above copyright notice and this paragraph | ||||
are included on all such copies and derivative works. However, this | ||||
document itself may not be modified in any way, such as by removing | ||||
the copyright notice or references to the Internet Society or other | ||||
Internet organizations, except as needed for the purpose of | ||||
developing Internet standards in which case the procedures for | ||||
copyrights defined in the Internet Standards process must be | ||||
followed, or as required to translate it into languages other than | ||||
English. | ||||
The limited permissions granted above are perpetual and will not be | ||||
revoked by the Internet Society or its successors or assigns. | ||||
Jamoussi, et. al. draft-ietf-mpls-cr-ldp-02.txt 36 | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |