draft-ietf-mpls-rsvp-lsp-tunnel-07.txt   draft-ietf-mpls-rsvp-lsp-tunnel-08.txt 
Network Working Group Daniel O. Awduche Network Working Group Daniel O. Awduche
Internet Draft UUNET (MCI Worldcom), Inc. Internet Draft Movaz Networks, Inc.
Expiration Date: February 2001 Expiration Date: August 2001
Lou Berger Lou Berger
LabN Consulting, LLC Movaz Networks, Inc.
Der-Hwa Gan Der-Hwa Gan
Juniper Networks, Inc. Juniper Networks, Inc.
Tony Li Tony Li
Procket Networks, Inc. Procket Networks, Inc.
Vijay Srinivasan Vijay Srinivasan
Cosine Communications, Inc. Cosine Communications, Inc.
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
August 2000 February 2001
RSVP-TE: Extensions to RSVP for LSP Tunnels RSVP-TE: Extensions to RSVP for LSP Tunnels
draft-ietf-mpls-rsvp-lsp-tunnel-07.txt draft-ietf-mpls-rsvp-lsp-tunnel-08.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. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the current status of any Internet-Draft, please check the To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html. Directory, see http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes the use of RSVP, including all the necessary This document describes the use of RSVP, including all the necessary
extensions, to establish label-switched paths (LSPs) in MPLS. Since extensions, to establish label-switched paths (LSPs) in MPLS. Since
the flow along an LSP is completely identified by the label applied the flow along an LSP is completely identified by the label applied
at the ingress node of the path, these paths may be treated as at the ingress node of the path, these paths may be treated as
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2 Overview .............................................. 9 2 Overview .............................................. 9
2.1 LSP Tunnels and Traffic Engineered Tunnels ............. 9 2.1 LSP Tunnels and Traffic Engineered Tunnels ............. 9
2.2 Operation of LSP Tunnels ............................... 9 2.2 Operation of LSP Tunnels ............................... 9
2.3 Service Classes ........................................ 12 2.3 Service Classes ........................................ 12
2.4 Reservation Styles ..................................... 12 2.4 Reservation Styles ..................................... 12
2.4.1 Fixed Filter (FF) Style ................................ 12 2.4.1 Fixed Filter (FF) Style ................................ 12
2.4.2 Wildcard Filter (WF) Style ............................. 12 2.4.2 Wildcard Filter (WF) Style ............................. 12
2.4.3 Shared Explicit (SE) Style ............................. 13 2.4.3 Shared Explicit (SE) Style ............................. 13
2.5 Rerouting Traffic Engineered Tunnels ................... 14 2.5 Rerouting Traffic Engineered Tunnels ................... 14
2.6 Path MTU ............................................... 15 2.6 Path MTU ............................................... 15
3 LSP Tunnel related Message Formats ..................... 16 3 LSP Tunnel related Message Formats ..................... 17
3.1 Path Message ........................................... 17 3.1 Path Message ........................................... 17
3.2 Resv Message ........................................... 17 3.2 Resv Message ........................................... 18
4 LSP Tunnel related Objects ............................. 18 4 LSP Tunnel related Objects ............................. 18
4.1 Label Object ........................................... 18 4.1 Label Object ........................................... 18
4.1.1 Handling Label Objects in Resv messages ................ 19 4.1.1 Handling Label Objects in Resv messages ................ 19
4.1.2 Non-support of the Label Object ........................ 20 4.1.2 Non-support of the Label Object ........................ 20
4.2 Label Request Object ................................... 21 4.2 Label Request Object ................................... 21
4.2.1 Label Request without Label Range ...................... 21 4.2.1 Label Request without Label Range ...................... 21
4.2.2 Label Request with ATM Label Range ..................... 21 4.2.2 Label Request with ATM Label Range ..................... 21
4.2.3 Label Request with Frame Relay Label Range ............. 23 4.2.3 Label Request with Frame Relay Label Range ............. 23
4.2.4 Handling of LABEL_REQUEST .............................. 24 4.2.4 Handling of LABEL_REQUEST .............................. 24
4.2.5 Non-support of the Label Request Object ................ 24 4.2.5 Non-support of the Label Request Object ................ 24
skipping to change at page 4, line 12 skipping to change at page 4, line 12
4.6 Session, Sender Template, and Filter Spec Objects ...... 41 4.6 Session, Sender Template, and Filter Spec Objects ...... 41
4.6.1 Session Object ......................................... 41 4.6.1 Session Object ......................................... 41
4.6.2 Sender Template Object ................................. 43 4.6.2 Sender Template Object ................................. 43
4.6.3 Filter Specification Object ............................ 44 4.6.3 Filter Specification Object ............................ 44
4.6.4 Reroute and Bandwidth Increase Procedure ............... 45 4.6.4 Reroute and Bandwidth Increase Procedure ............... 45
4.7 Session Attribute Object ............................... 46 4.7 Session Attribute Object ............................... 46
4.7.1 Format without resource affinities ..................... 46 4.7.1 Format without resource affinities ..................... 46
4.7.2 Format with resource affinities ........................ 48 4.7.2 Format with resource affinities ........................ 48
4.7.3 Procedures applying to both C-Types .................... 49 4.7.3 Procedures applying to both C-Types .................... 49
4.7.4 Resource Affinity Procedures .......................... 51 4.7.4 Resource Affinity Procedures .......................... 51
4.8 Tspec and Flowspec Object for CoS Service ............. 52 5 Hello Extension ........................................ 53
5 Hello Extension ........................................ 54 5.1 Hello Message Format ................................... 54
5.1 Hello Message Format ................................... 55 5.2 HELLO Object formats ................................... 54
5.2 HELLO Object formats ................................... 55 5.2.1 HELLO REQUEST object ................................... 54
5.2.1 HELLO REQUEST object ................................... 55 5.2.2 HELLO ACK object ....................................... 55
5.2.2 HELLO ACK object ....................................... 56 5.3 Hello Message Usage .................................... 55
5.3 Hello Message Usage .................................... 56 5.4 Multi-Link Considerations .............................. 57
5.4 Multi-Link Considerations .............................. 58 5.5 Compatibility .......................................... 57
5.5 Compatibility .......................................... 58 6 Security Considerations ................................ 58
6 Security Considerations ................................ 59 7 IANA Considerations .................................... 58
7 IANA Considerations .................................... 59
8 Intellectual Property Considerations ................... 59 8 Intellectual Property Considerations ................... 59
9 Acknowledgments ........................................ 60 9 Acknowledgments ........................................ 59
10 References ............................................. 60 10 References ............................................. 59
11 Authors' Addresses ..................................... 61 11 Authors' Addresses ..................................... 60
1. Introduction 1. Introduction
Section 2.9 of the MPLS architecture [2] defines a label distribution Section 2.9 of the MPLS architecture [2] defines a label distribution
protocol as a set of procedures by which one Label Switched Router protocol as a set of procedures by which one Label Switched Router
(LSR) informs another of the meaning of labels used to forward (LSR) informs another of the meaning of labels used to forward
traffic between and through them. The MPLS architecture does not traffic between and through them. The MPLS architecture does not
assume a single label distribution protocol. This document is a assume a single label distribution protocol. This document is a
specification of extensions to RSVP for establishing label switched specification of extensions to RSVP for establishing label switched
paths (LSPs) in Multi-protocol Label Switching (MPLS) networks. paths (LSPs) in Multi-protocol Label Switching (MPLS) networks.
skipping to change at page 16, line 20 skipping to change at page 16, line 20
Using the terminology defined in [5], an LSR MUST execute the Using the terminology defined in [5], an LSR MUST execute the
following algorithm: following algorithm:
1. Let N be the number of bytes in the label stack (i.e, 4 times 1. Let N be the number of bytes in the label stack (i.e, 4 times
the number of label stack entries) including labels to be added the number of label stack entries) including labels to be added
by this node. by this node.
2. Let M be the smaller of the "Maximum Initially Labeled IP 2. Let M be the smaller of the "Maximum Initially Labeled IP
Datagram Size" or of (Path MTU - N). Datagram Size" or of (Path MTU - N).
When the size of the datagram (without labels) exceeds the value When the size of an IPv4 datagram (without labels) exceeds the
of M, value of M,
If the DF bit is not set in the IP header, then If the DF bit is not set in the IPv4 header, then
(a) the datagram MUST be broken into fragments, each of whose (a) the datagram MUST be broken into fragments, each of whose
size is no greater than M, and size is no greater than M, and
(b) each fragment MUST be labeled and then forwarded. (b) each fragment MUST be labeled and then forwarded.
If the DF bit is set in the IP header, then If the DF bit is set in the IPv4 header, then
(a) the datagram MUST NOT be forwarded (a) the datagram MUST NOT be forwarded
(b) Create an ICMP Destination Unreachable Message: (b) Create an ICMP Destination Unreachable Message:
i. set its Code field [12] to "Fragmentation Required i. set its Code field [12] to "Fragmentation Required
and DF Set", and DF Set",
ii. set its Next-Hop MTU field [13] to M ii. set its Next-Hop MTU field [13] to M
(c) If possible, transmit the ICMP Destination Unreachable (c) If possible, transmit the ICMP Destination Unreachable
Message to the source of the of the discarded datagram. Message to the source of the of the discarded datagram.
When the size of an IPv6 datagram (without labels) exceeds the
value of M,
(a) the datagram MUST NOT be forwarded
(b) Create an ICMP Packet too Big Message with the
Next-Hop link MTU field [14] set to M
(c) If possible, transmit the ICMP Packet too Big Message
to the source of the of the discarded datagram.
3. LSP Tunnel related Message Formats 3. LSP Tunnel related Message Formats
Five new objects are defined in this section: Five new objects are defined in this section:
Object name Applicable RSVP messages Object name Applicable RSVP messages
--------------- ------------------------ --------------- ------------------------
LABEL_REQUEST Path LABEL_REQUEST Path
LABEL Resv LABEL Resv
EXPLICIT_ROUTE Path EXPLICIT_ROUTE Path
RECORD_ROUTE Path, Resv RECORD_ROUTE Path, Resv
skipping to change at page 41, line 13 skipping to change at page 41, line 13
10 Unsupported L3PID 10 Unsupported L3PID
For the Notify Error Code, the 16 bits of the Error Value field are: For the Notify Error Code, the 16 bits of the Error Value field are:
ss00 cccc cccc cccc ss00 cccc cccc cccc
The high order bits are as defined under Error Code 1. (See [1]). The high order bits are as defined under Error Code 1. (See [1]).
When ss = 00, the following subcodes are defined: When ss = 00, the following subcodes are defined:
1 RRO too large for MTU 1 RRO too large for MTU
2 RRO notification 2 RRO notification
3 Tunnel locally repaired
4.6. Session, Sender Template, and Filter Spec Objects 4.6. Session, Sender Template, and Filter Spec Objects
New C-Types are defined for the SESSION, SENDER_TEMPLATE and New C-Types are defined for the SESSION, SENDER_TEMPLATE and
FILTER_SPEC objects. FILTER_SPEC objects.
The LSP_TUNNEL objects have the following format: The LSP_TUNNEL objects have the following format:
4.6.1. Session Object 4.6.1. Session Object
4.6.1.1. LSP_TUNNEL_IPv4 Session Object 4.6.1.1. LSP_TUNNEL_IPv4 Session Object
skipping to change at page 50, line 44 skipping to change at page 50, line 44
If the requested bandwidth is not available a PathErr message is If the requested bandwidth is not available a PathErr message is
returned with an Error Code of 01, Admission Control Failure, and an returned with an Error Code of 01, Admission Control Failure, and an
Error Value of 0x0002. The first 0 in the Error Value indicates a Error Value of 0x0002. The first 0 in the Error Value indicates a
globally defined subcode and is not informational. The 002 indicates globally defined subcode and is not informational. The 002 indicates
"requested bandwidth unavailable". "requested bandwidth unavailable".
If the requested bandwidth is less than the unused bandwidth then If the requested bandwidth is less than the unused bandwidth then
processing is complete. If the requested bandwidth is available, but processing is complete. If the requested bandwidth is available, but
is in use by lower priority sessions, then lower priority sessions is in use by lower priority sessions, then lower priority sessions
(beginning with the lowest priority) can be pre-empted to free the (beginning with the lowest priority) MAY be pre-empted to free the
necessary bandwidth. necessary bandwidth.
When pre-emption is supported, each pre-empted reservation triggers a When pre-emption is supported, each pre-empted reservation triggers a
TC_Preempt() upcall to local clients, passing a subcode that TC_Preempt() upcall to local clients, passing a subcode that
indicates the reason. A ResvErr and/or PathErr with the code "Policy indicates the reason. A ResvErr and/or PathErr with the code "Policy
Control failure" SHOULD be sent toward the downstream receivers and Control failure" SHOULD be sent toward the downstream receivers and
upstream senders. upstream senders.
The support of local-protection is OPTIONAL. A node may recognize The support of local-protection is OPTIONAL. A node may recognize
the local-protection Flag but may be unable to perform the requested the local-protection Flag but may be unable to perform the requested
skipping to change at page 52, line 30 skipping to change at page 52, line 30
3. Include-all 3. Include-all
This test accepts a link only if the link carries all of the This test accepts a link only if the link carries all of the
attributes in the set. attributes in the set.
(include-all == 0) | (((link-attr & include-all) ^ include- (include-all == 0) | (((link-attr & include-all) ^ include-
all) == 0) all) == 0)
For a link to be acceptable, all three tests MUST pass. If the test For a link to be acceptable, all three tests MUST pass. If the test
fails a error message fails, the node SHOULD send a PathErr message with an error code of
"Routing Problem" and an error value of "no route available toward
destination".
If a Path message contains multiple SESSION_ATTRIBUTE objects, only If a Path message contains multiple SESSION_ATTRIBUTE objects, only
the first SESSION_ATTRIBUTE object is meaningful. Subsequent the first SESSION_ATTRIBUTE object is meaningful. Subsequent
SESSION_ATTRIBUTE objects can be ignored and need not be forwarded. SESSION_ATTRIBUTE objects can be ignored and need not be forwarded.
All RSVP routers, whether they support the SESSION_ATTRIBUTE object All RSVP routers, whether they support the SESSION_ATTRIBUTE object
or not, SHALL forward the object unmodified. The presence of non- or not, SHALL forward the object unmodified. The presence of non-
RSVP routers anywhere between senders and receivers has no impact on RSVP routers anywhere between senders and receivers has no impact on
this object. this object.
4.8. Tspec and Flowspec Object for Class-of-Service Service
An LSP may not need bandwidth reservations or QoS guarantees. Such
LSPs can be used to deliver best-effort traffic, even if RSVP is used
for setting up LSPs. When resources do not have to be allocated to
the LSP, the Class-of-Service service SHOULD be used.
The Class-of-Service FLOWSPEC allows indication of a Class of Service
(CoS) value that should be used when handling data packets associated
with the request.
The same format is used both for SENDER_TSPEC object and FLOWSPEC
objects. The formats are:
Class-of-Service SENDER_TSPEC object: Class = 12, C-Type = 3
Class-of-Service FLOWSPEC object: Class = 9, C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CoS | Maximum Packet Size [M] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
CoS
Indicates the Class of Service (CoS) of the data traffic
associated with the request. A value of zero (0) indicates
that associated traffic is "Best-Effort". Specifically no
service assurances are being requested from the network. The
intent is to enable networks to support the IP ToS Octet as
defined in RFC1349 [7]. It is noted that there is ongoing work
within the IETF to update the use of the IP ToS Octet. In
particular, RFC2474 [8], obsoletes RFC1349. However at this
time the new uses of this field (now termed the DS byte) are
still being defined. Non-zero values have local significance.
The translation from a specific value to an allocation is a
local administrative decision.
M
This parameter is set in Resv messages by the receiver based on
information in arriving RSVP SENDER_TSPEC objects. For shared
reservations, the smallest value received across all associated
senders is used. When the object is contained in Path
messages, this parameter is updated at each hop with the lesser
of the received value and the MTU of the outgoing interface.
There is no Adspec associated with the Class-of-Service SENDER_TSPEC.
Either the Adspec is omitted or an int-serv adspec with only the
Default General Characterization Parameters is used.
5. Hello Extension 5. Hello Extension
The RSVP Hello extension enables RSVP nodes to detect when a The RSVP Hello extension enables RSVP nodes to detect when a
neighboring node is not reachable. The mechanism provides node to neighboring node is not reachable. The mechanism provides node to
node failure detection. When such a failure is detected it is node failure detection. When such a failure is detected it is
handled much the same as a link layer communication failure. This handled much the same as a link layer communication failure. This
mechanism is intended to be used when notification of link layer mechanism is intended to be used when notification of link layer
failures is not available and unnumbered links are not used, or when failures is not available and unnumbered links are not used, or when
the failure detection mechanisms provided by the link layer are not the failure detection mechanisms provided by the link layer are not
sufficient for timely node failure detection. sufficient for timely node failure detection.
skipping to change at page 59, line 20 skipping to change at page 58, line 20
according to source and destination addresses as well as port according to source and destination addresses as well as port
numbers. In this specification, filtering occurs only on the basis numbers. In this specification, filtering occurs only on the basis
of an incoming label. For this reason an administration may wish to of an incoming label. For this reason an administration may wish to
limit the domain over which LSP tunnels can be established. This can limit the domain over which LSP tunnels can be established. This can
be accomplished by setting filters on various ports to deny action on be accomplished by setting filters on various ports to deny action on
a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7) a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7)
or LSP_TUNNEL_IPv6 (8). or LSP_TUNNEL_IPv6 (8).
7. IANA Considerations 7. IANA Considerations
The responsible Internet authority (presently called the IANA) IANA assigns values to RSVP protocol parameters. Within the current
assigns values to RSVP protocol parameters. With the current
document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are
defined. Each of these objects contain subobjects. This section defined. Each of these objects contain subobjects. This section
defines the rules for the assignment of subobject numbers. This defines the rules for the assignment of subobject numbers. This
section uses the terminology of BCP 26 "Guidelines for Writing an section uses the terminology of BCP 26 "Guidelines for Writing an
IANA Considerations Section in RFCs". IANA Considerations Section in RFCs" [15].
EXPLICIT_ROUTE Subobject Type EXPLICIT_ROUTE Subobject Type
EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies
the function of the subobject. There are no range restrictions. the function of the subobject. There are no range restrictions.
All possible values except zero are available for assignment. All possible values except zero are available for assignment.
Following the policies outlined in [15], subobject types in the
range 0x00 - 0x3F are allocated through an IETF Consensus action,
codes in the range 00x40 - 0x5F are allocated as First Come First
Served, and codes in the range 0x60 - 0x7F are reserved for
Private Use.
ROUTE_RECORD Subobject Type ROUTE_RECORD Subobject Type
ROUTE_RECORD Subobject Type is an 8-bit number that identifies the ROUTE_RECORD Subobject Type is an 8-bit number that identifies the
function of the subobject. There are no range restrictions. All function of the subobject. There are no range restrictions. All
possible values except zero are available for assignment. possible values except zero are available for assignment.
Following the policies outlined in [15], subobject types in the
range 0x00 - 0x7F are allocated through an IETF Consensus action,
codes in the range 00x80 - 0xBF are allocated as First Come First
Served, and codes in the range 0xC0 - 0xFF are reserved for
Private Use.
8. Intellectual Property Considerations 8. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
9. Acknowledgments 9. Acknowledgments
This document contains ideas as well as text that have appeared in This document contains ideas as well as text that have appeared in
skipping to change at page 61, line 11 skipping to change at page 60, line 19
[11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", [11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997. RFC 2210, September 1997.
[12] Postel, J., "Internet Control Message Protocol", RFC 792, [12] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981. September 1981.
[13] Mogul, J. & Deering, S., "Path MTU Discovery", RFC 1191, [13] Mogul, J. & Deering, S., "Path MTU Discovery", RFC 1191,
November 1990. November 1990.
[14] Conta, A. & Deering, S., "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463,
December 1998.
[15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
11. Authors' Addresses 11. Authors' Addresses
Daniel O. Awduche Daniel O. Awduche
UUNET (MCI Worldcom), Inc Movaz Networks, Inc.
3060 Williams Drive 7926 Jones Branch Drive, Suite 615
Fairfax, VA 22031 McLean, VA 22102
Voice: +1 703 208 5277 Voice: +1 703 847 7350
Email: awduche@uu.net Email: awduche@movaz.com
Lou Berger Lou Berger
LabN Consulting, LLC Movaz Networks, Inc.
Voice: +1 301 468 9228 7926 Jones Branch Drive, Suite 615
Email: lberger@labn.net McLean, VA 22102
Voice: +1 703 847 1801
Email: lberger@movaz.com
Der-Hwa Gan Der-Hwa Gan
Juniper Networks, Inc. Juniper Networks, Inc.
385 Ravendale Drive 385 Ravendale Drive
Mountain View, CA 94043 Mountain View, CA 94043
Voice: +1 650 526
Email: dhg@juniper.net Email: dhg@juniper.net
Tony Li Tony Li
Procket Networks Procket Networks
3910 Freedom Circle, Ste. 102A 3910 Freedom Circle, Ste. 102A
Santa Clara CA 95054 Santa Clara CA 95054
Email: tony1@home.net Email: tony1@home.net
Vijay Srinivasan Vijay Srinivasan
Cosine Communications, Inc. Cosine Communications, Inc.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/