abstract node described by the second ER-Hop. If so, the node
selects a particular next hop which is a member of the abstract
node. The node then deletes the first ER-Hop and continues
processing with section 4.8.2.
5. Next, the node selects a next hop within the abstract node of
the first ER-Hop that is along the path to the abstract node of
the second ER-Hop. If no such path exists then there are two
cases:
5.a If the second ER-Hop is a strict ER-Hop, then there is an
error and the node should return a "Bad Strict Node Error"
status.
5.b Otherwise, if the second ER-Hop is a loose ER-Hop, then the
node selects any next hop that is along the path to the
next 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" status.
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.
4.8.2. Adding ER-Hops to the explicit route TLV
After selecting a next hop, the node may alter the explicit route in
the following ways.
If, as part of executing the algorithm in section 4.8.1, the explicit
route TLV is removed, the node may add a new explicit route TLV.
Otherwise, if the node is a member of the abstract node for the first
ER-Hop, then a series of ER-Hops may be inserted before the first
ER-Hop or may replace the first ER-Hop. Each ER-Hop in this series
must denote an abstract node that is a subset of the current abstract
node.
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.
4.9 Route Pinning TLV
Section 2.4 describes the use of route pinning. The encoding of the
Route Pinning TLV is as follows:
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|0| Type = 0x0823 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the Pinning-TLV
Type = 0x0823
Length
Specifies the length of the value field in bytes = 4.
P Bit
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
requested
Reserved
Zero on transmission. Ignored on receipt.
4.10 CR-LSP FEC Element
A new FEC element is introduced in this specification to support CR-
LSPs. A FEC TLV containing a FEC of Element type CR-LSP (0x04) is a
CR-LSP FEC TLV. The CR-LSP FEC Element is an opaque FEC to be used
only in Messages of CR-LSPs.
A single FEC element MUST be included in the Label Request Message.
The FEC Element SHOULD be the CR-LSP FEC Element. However, one of
the other FEC elements (Type=0x01, 0x02, 0x03) defined in [1] MAY be
in CR-LDP messages instead of the CR-LSP FEC Element for certain
applications. A FEC TLV containing a FEC of Element type CR-LSP
(0x04) is a CR-LSP FEC TLV.
FEC Element Type Value
Type name
CR-LSP 0x04 No value; i.e., 0 value octets;
The CR-LSP FEC TLV encoding is as follows:
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|0| Type = 0x0100 | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CR-LSP (4) |
+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the FEC TLV
Type = 0x0100
Length
Specifies the length of the value field in bytes = 1.
CR-LSP FEC Element Type
0x04
5. IANA Considerations
CR-LDP defines the following name spaces, which require management:
- TLV types.
- FEC types.
- Status codes.
The following sections provide guidelines for managing these name
spaces.
5.1 TLV Type Name Space
RFC3036 [1] defines the LDP TLV name space. This document further
subdivides the range of RFC3036 from that TLV space for TLVs
associated with the CR-LDP in the range 0x0800 - 0x08FF.
Following the policies outlined in [IANA], TLV types in this range
are allocated through an IETF Consensus action.
Initial values for this range are specified in the following table:
TLV Type
-------------------------------------- ----------
Explicit Route TLV 0x0800
Ipv4 Prefix ER-Hop TLV 0x0801
Ipv6 Prefix ER-Hop TLV 0x0802
Autonomous System Number ER-Hop TLV 0x0803
LSP-ID ER-Hop TLV 0x0804
Traffic Parameters TLV 0x0810
Preemption TLV 0x0820
LSPID TLV 0x0821
Resource Class TLV 0x0822
Route Pinning TLV 0x0823
5.2 FEC Type Name Space
RFC3036 defines the FEC Type name space. Further, RFC3036 has
assigned values 0x00 through 0x03. FEC types 0 through 127 are
available for assignment through IETF consensus action. This
specification makes the following additional assignment, using the
policies outlined in [IANA]:
FEC Element Type
-------------------------------------- ----------
CR-LSP FEC Element 0x04
5.3 Status Code Space
RFC3036 defines the Status Code name space. This document further
subdivides the range of RFC3036 from that TLV space for TLVs
associated with the CR-LDP in the range 0x04000000 - 0x040000FF.
Following the policies outlined in [IANA], TLV types in this range
are allocated through an IETF Consensus action.
Initial values for this range are specified in the following table:
Status Code Type
-------------------------------------- ----------
Bad Explicit Routing TLV Error 0x04000001
Bad Strict Node Error 0x04000002
Bad Loose Node Error 0x04000003
Bad Initial ER-Hop Error 0x04000004
Resource Unavailable 0x04000005
Traffic Parameters Unavailable 0x04000006
LSP Preempted 0x04000007
Modify Request Not Supported 0x04000008
6. Security Considerations
CR-LDP inherits the same security mechanism described in Section 4.0
of [1] to protect against the introduction of spoofed TCP segments
into LDP session connection streams.
7. Acknowledgments
The messages used to signal the CR-LSP setup are based on the work
done by the LDP [1] design team.
The list of authors provided with this document is a reduction of the
original list. Currently listed authors wish to acknowledge that a
substantial amount was also contributed to this work by:
Osama Aboul-Magd, Peter Ashwood-Smith, Joel Halpern,
Fiffi Hellstrand, Kenneth Sundell and Pasi Vaananen.
The authors would also like to acknowledge the careful review and
comments of Ken Hayward, Greg Wright, Geetha Brown, Brian Williams,
Paul Beaubien, Matthew Yuen, Liam Casey, Ankur Anand and Adrian
Farrel.
8. Intellectual Property Consideration
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
9. References
[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
Thomas, "Label Distribution Protocol Specification", RFC3036,
January 2001.
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC3031, January 2001.
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus,
"Requirements for Traffic Engineering Over MPLS", RFC2702,
September 1999.
[4] Gleeson, B., Lin, A., Heinanen, Armitage, G. and A. Malis, "A
Framework for IP Based Virtual Private Networks", RFC2764,
February 2000.
[5] Ash, J., Girish, M., Gray, E., Jamoussi, B. and G. Wright,
"Applicability Statement for CR-LDP", RFC3213, January 2002.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[7] Boscher, C., Cheval, P., Wu, L. and E. Gray, "LDP State Machine",
RFC3215, January 2002.
[8] Ash, J., Lee, Y., Ashwood-Smith, P., Jamoussi, B., Fedyk, D.,
Skalecki, D. and L. Li, "LSP Modification Using CR-LDP", RFC
3214, January 2002.
Appendix A: CR-LSP Establishment Examples
A.1 Strict Explicit Route Example
This appendix provides an example for the setup of a strictly routed
CR-LSP. In this example, a specific node represents each abstract
node.
The sample network used here is a four node network with two edge
LSRs and two core LSRs as follows:
abc
LSR1------LSR2------LSR3------LSR4
LSR1 generates a Label Request Message as described in Section 3.1 of
this document and sends it to LSR2. This message includes the CR-
TLV.
A vector of three ER-Hop TLVs <a, b, c> composes the ER-TLV. The ER-
Hop TLVs used in this example are of type 0x0801 (IPv4 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 this document takes
place:
1. The node LSR2 is part of the abstract node described by the
first hop <a>. Therefore, the first step passes the test. Go
to step 2.
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
ER-Hop <b>. Go to Step 4.
4. LSR2 determines that it is topologically adjacent to the
abstract node described by the second ER-Hop <b>. LSR2 selects
a next hop (LSR3) which is the abstract node. LSR2 deletes the
first ER-Hop <a> from the ER-TLV, which now becomes <b, c>.
Processing continues with Section 4.8.2.
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-
TLV.
Also, LSR2 is not a member of the abstract node described by the
first ER-Hop <b>.
Finally, the first ER-Hop <b> is a strict hop.
Therefore, processing section 4.8.2 does not result in the insertion
of new ER-Hops. The selection of the next hop has been already done
is step 4 of Section 4.8.1 and the processing of the ER-TLV is
completed at LSR2. In this case, the Label Request 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
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:
1. The node LSR4 is part of the abstract node described by the
first hop <c>. Therefore, the first step passes the test. Go
to step 2.
2. There is no second ER-Hop, this indicates the end of the CR-
LSP. The ER-TLV is removed from the Label Request Message.
Processing continues with Section 4.8.2.
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. LSR4
does not add a new ER-TLV.
Therefore, processing section 4.8.2 does not result in the insertion
of new ER-Hops. This indicates the end of the CR-LSP and the
processing of the ER-TLV is completed at LSR4.
At LSR4, processing of Section 3.2 is invoked. The first condition
is satisfied (LSR4 is the egress end of the CR-LSP and upstream
mapping has been requested). Therefore, a Label Mapping Message is
generated by LSR4 and sent to LSR3.
At LSR3, the processing of Section 3.2 is invoked. The second
condition is satisfied (LSR3 received a mapping from its downstream
next hop LSR4 for a CR-LSP for which an upstream request is still
pending). Therefore, a Label Mapping Message is generated by LSR3
and sent to LSR2.
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
CR-LSP setup.
A.2 Node Groups and Specific Nodes Example
A request at ingress LSR to setup a CR-LSP might originate from a
management system or an application, the details are implementation
specific.
The ingress LSR uses information provided by the management system or
the application and possibly also information from the routing
database to calculate the explicit route and to create the Label
Request Message.
The Label request message carries together with other necessary
information an ER-TLV defining the explicitly routed path. In our
example the list of hops in the ER-Hop TLV is supposed to contain an
abstract node representing a group of nodes, an abstract node
representing a specific node, another abstract node representing a
group of nodes, and an abstract node representing a specific egress
point.
In--{Group 1}--{Specific A}--{Group 2}--{Specific Out: B}
The ER-TLV contains four ER-Hop TLVs:
1. An ER-Hop TLV that specifies a group of LSR valid for the first
abstract node representing a group of nodes (Group 1).
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
second abstract node representing a group of nodes (Group 2).
4. An ER-Hop TLV that indicates the specific egress point for the
CR-LSP (Node B).
All the ER-Hop TLVs are strictly routed nodes.
The setup procedure for this CR-LSP works as follows:
1. The ingress node sends the Label Request Message to a node
that is a member the group of nodes indicated in the first ER-
Hop TLV, following normal routing for the specific node (A).
2. The node that receives the message identifies itself as part
of the group indicated in the first ER-Hop TLV, and that it is
not the specific node (A) in the second. Further it 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
Message to another node that is part of the group indicated in
the first ER-Hop TLV (Group 1), following normal routing for
the specific node (A).
4. The node that receives the message identifies itself as part
of the group indicated in the first ER-Hop TLV, and that it is
not the specific node (A) in the second ER-Hop TLV. 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
Message to the specific node (A).
6. The specific node (A) recognizes itself in the first ER-Hop
TLV. Removes the specific ER-Hop TLV.
7. It sends a Label Request Message to a node that is a member of
the group (Group 2) indicated in the ER-Hop TLV.
8. The node that receives the message identifies itself as part
of the group indicated in the first ER-Hop TLV, further it
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
(B).
10. The specific egress node (B) recognizes itself as the egress
for the CR-LSP, it returns a Label Mapping Message, that will
traverse the same path as the Label Request Message in the
opposite direction.
Appendix B. QoS Service Examples
B.1 Service Examples
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
network nodes. The rules define the traffic conditioning actions
that are implemented at the edge and they include policing with pass,
mark, and drop capabilities. The edge rules are expected to be
defined by the mutual agreements between the service providers and
their customers and they will constitute an essential part of the
SLA. Therefore edge rules are not included in the signaling
protocol.
Packet treatment at a network node is usually referred to as the
local behavior. Local behavior could be specified in many ways. One
example for local behavior specification is the service frequency
introduced in section 4.3.2.1, together with the resource reservation
rules implemented at the nodes.
Edge rules and local behaviors can be viewed as the main building
blocks for the end-to-end service construction. The following table
illustrates the applicability of the building block approach for
constructing different services including those defined for ATM.
Service PDR PBS CDR CBS EBS Service Conditioning
Examples Frequency Action
DS S S =PDR =PBS 0 Frequent drop>PDR
TS S S S S 0 Unspecified drop>PDR,PBS
mark>CDR,CBS
BE inf inf inf inf 0 Unspecified -
FRS S S CIR ~B_C ~B_E Unspecified drop>PDR,PBS
mark>CDR,CBS,EBS
ATM-CBR PCR CDVT =PCR =CDVT 0 VeryFrequent drop>PCR
ATM-VBR.3(rt) PCR CDVT SCR MBS 0 Frequent drop>PCR
mark>SCR,MBS
ATM-VBR.3(nrt) PCR CDVT SCR MBS 0 Unspecified drop>PCR
mark>SCR,MBS
ATM-UBR PCR CDVT - - 0 Unspecified drop>PCR
ATM-GFR.1 PCR CDVT MCR MBS 0 Unspecified drop>PCR
ATM-GFR.2 PCR CDVT MCR MBS 0 Unspecified drop>PCR
mark>MCR,MFS
int-serv-CL p m r b 0 Frequent drop>p
drop>r,b
S= User specified
In the above table, the DS refers to a delay sensitive service where
the network commits to deliver with high probability user datagrams
at a rate of PDR with minimum delay and delay requirements. Datagrams
in excess of PDR will be discarded.
The TS refers to a generic throughput sensitive service where the
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 but datagrams in excess of CDR would have a lower probability of
being delivered.
The BE is the best effort service and it implies that there are no
expected service guarantees from the network.
B.2 Establishing CR-LSP Supporting Real-Time Applications
In this scenario the customer needs to establish an LSP for
supporting real-time applications such as voice and video. The
Delay-sensitive (DS) service is requested in this case.
The first step is the specification of the traffic parameters in the
signaling message. The two parameters of interest to the DS service
are the PDR and the PBS and the user based on his requirements
specifies their values. Since all the traffic parameters are
included in the signaling message, appropriate values must be
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
whether the parameter values are subject to negotiation is flagged.
The transport characteristics of the DS service require Frequent
frequency to be requested to reflect the real-time delay requirements
of the service.
In addition to the transport characteristics, both the network
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 of the service level agreement (SLA) negotiation and is not
included in the signaling protocol. For DS service, the edge action
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
and the LSP is established following the normal LDP procedures. Each
LSR applies its admission control rules. If sufficient resources are
not available and the parameter values are subject to negotiation,
then the LSR could negotiate down the PDR, the PBS, or both.
The new parameter values are echoed back in the Label Mapping
Message. LSRs might need to re-adjust their resource reservations
based on the new traffic parameter values.
B.3 Establishing CR-LSP Supporting Delay Insensitive Applications
In this example we assume that a throughput sensitive (TS) service is
requested. For resource allocation the user assigns values for PDR,
PBS, CDR, and CBS. The negotiation flag is set if the traffic
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.
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
discard precedence values for all packets that exceed CDR and the
CBS. The edge rules will also include dropping of packets that
conform to neither PDR nor PBS.
Each LSR of the LSP is expected to run its admission control rules
and negotiate traffic parameters down if sufficient resources do not
exist. The new parameter values are echoed back in the Label Mapping
Message. LSRs might need to re-adjust their resources based on the
new traffic parameter values.
10. Author's Addresses
Loa Andersson
Utfors Bredband AB
Rasundavagen 12 169 29
Solna
Phone: +46 8 5270 50 38
EMail: loa.andersson@utfors.se
Ross Callon
Juniper Networks
1194 North Mathilda Avenue,
Sunnyvale, CA 94089
Phone: 978-692-6724
EMail: rcallon@juniper.net
Ram Dantu
Netrake Corporation
3000 Technology Drive, #100
Plano Texas, 75024
Phone: 214 291 1111
EMail: rdantu@netrake.com
Paul Doolan
On The Beach Consulting Corp
34 Mill Pond Circle
Milford MA 01757
Phone 617 513 852
EMail: pdoolan@acm.org
Nancy Feldman
IBM Research
30 Saw Mill River Road
Hawthorne, NY 10532
Phone: 914-784-3254
EMail: Nkf@us.ibm.com
Andre Fredette
ANF Consulting
62 Duck Pond Dr.
Groton, MA 01450
EMail: afredette@charter.net
Eric Gray
600 Federal Drive
Andover, MA 01810
Phone: (978) 689-1610
EMail: eric.gray@sandburst.com
Juha Heinanen
Song Networks, Inc.
Hallituskatu 16
33200 Tampere, Finland
EMail: jh@song.fi
Bilel Jamoussi
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
USA
Phone: +1 978 288-4506
Mail: Jamoussi@nortelnetworks.com
Timothy E. Kilty
Island Consulting
Phone: (978) 462 7091
EMail: tim-kilty@mediaone.net
Andrew G. Malis
Vivace Networks
2730 Orchard Parkway
San Jose, CA 95134
Phone: +1 408 383 7223
EMail: Andy.Malis@vivacenetworks.com
Muckai K Girish
Atoga Systems
49026 Milmont Drive
Fremont, CA 94538
EMail: muckai@atoga.com
Tom Worster
Phone: 617 247 2624
EMail: fsb@thefsb.org
Liwen Wu
Cisco Systems
250 Apollo Drive
Chelmsford, MA. 01824
Phone: 978-244-3087
EMail: liwwu@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.