draft-ietf-mpls-rsvp-lsp-tunnel-02.txt   draft-ietf-mpls-rsvp-lsp-tunnel-03.txt 
MPLS Working Group Daniel O. Awduche
Network Working Group Daniel O. Awduche Internet Draft UUNET (MCI Worldcom), Inc.
Internet Draft UUNET Worldcom, Inc. Expiration Date: March 2000
Expiration Date: September 1999
Lou Berger Lou Berger
FORE Systems, Inc. LabN Consulting
Der-Hwa Gan Der-Hwa Gan
Juniper Networks, Inc. Juniper Networks, Inc.
Tony Li Tony Li
Juniper Networks, Inc. Procket Networks, Inc.
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
Vijay Srinivasan Vijay Srinivasan
Torrent Networks, Inc. Torrent Networks, Inc.
March 1999 September 1999
Extensions to RSVP for LSP Tunnels Extensions to RSVP for LSP Tunnels
draft-ietf-mpls-rsvp-lsp-tunnel-02.txt draft-ietf-mpls-rsvp-lsp-tunnel-03.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 39 skipping to change at page 3, line 39
4.3 Explicit Route Object .................................. 21 4.3 Explicit Route Object .................................. 21
4.3.1 Applicability .......................................... 22 4.3.1 Applicability .......................................... 22
4.3.2 Semantics of the Explicit Route Object ................. 22 4.3.2 Semantics of the Explicit Route Object ................. 22
4.3.3 Subobjects ............................................. 23 4.3.3 Subobjects ............................................. 23
4.3.4 Processing of the Explicit Route Object ................ 27 4.3.4 Processing of the Explicit Route Object ................ 27
4.3.5 Loops .................................................. 29 4.3.5 Loops .................................................. 29
4.3.6 Non-support of the Explicit Route Object ............... 29 4.3.6 Non-support of the Explicit Route Object ............... 29
4.4 Record Route Object .................................... 29 4.4 Record Route Object .................................... 29
4.4.1 Subobjects ............................................. 30 4.4.1 Subobjects ............................................. 30
4.4.2 Applicability .......................................... 32 4.4.2 Applicability .......................................... 32
4.4.3 Handling RRO ........................................... 32 4.4.3 Handling RRO ........................................... 33
4.4.4 Loop Detection ......................................... 33 4.4.4 Loop Detection ......................................... 34
4.4.5 Non-support of RRO ..................................... 34 4.4.5 Non-support of RRO ..................................... 35
4.5 Error Subcodes for ERO and RRO ......................... 34 4.5 Error Codes for ERO and RRO ............................ 35
4.6 Session, Sender Template, and Filter Spec Objects ...... 35 4.6 Session, Sender Template, and Filter Spec Objects ...... 36
4.6.1 Session Object ......................................... 35 4.6.1 Session Object ......................................... 36
4.6.2 Sender Template Object ................................. 36 4.6.2 Sender Template Object ................................. 37
4.6.3 Filter Specification Object ............................ 37 4.6.3 Filter Specification Object ............................ 37
4.6.4 Reroute Procedure ...................................... 37 4.6.4 Reroute Procedure ...................................... 38
4.7 Session Attribute Object ............................... 38 4.7 Session Attribute Object ............................... 39
4.8 Flowspec Object for Class-of-Service Service .......... 41 4.8 Tspec and Flowspec Object for Class-of-Service Service... 41
5 Acknowledgments ........................................ 42 5 Security Considerations ................................ 43
6 References ............................................. 42 6 Intellectual Property Considerations ................... 43
7 Authors' Addresses ..................................... 43 7 Acknowledgments ........................................ 43
8 References ............................................. 43
9 Authors' Addresses ..................................... 45
1. Introduction and Background 1. Introduction and Background
1.1. Introduction 1.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
skipping to change at page 11, line 15 skipping to change at page 11, line 15
A single multipoint-to-point label-switched-path is created for all A single multipoint-to-point label-switched-path is created for all
senders to the session. On links that senders to the session share, a senders to the session. On links that senders to the session share, a
single label value is allocated to the session. If there is only one single label value is allocated to the session. If there is only one
sender, the LSP looks like a normal point-to-point connection. When sender, the LSP looks like a normal point-to-point connection. When
multiple senders are present, a multipoint-to-point LSP (a reversed multiple senders are present, a multipoint-to-point LSP (a reversed
tree) is created. tree) is created.
This style is useful for applications in which not all senders send This style is useful for applications in which not all senders send
traffic at the same time. A phone conference, for example, is an traffic at the same time. A phone conference, for example, is an
application where not all speakers talk at the same time. If, application where not all speakers talk at the same time. If,
however, the reservation requested is greater than a single sender's however, all senders send simultaneously, then there is no means of
requirements, then the reserved bandwidth on links close to the some getting the proper reservations made. Either the reserved bandwidth
senders may be greater than what is required. This restricts the on links close to the destination will be less than what is required
applicability of WF for traffic engineering purposes. or then the reserved bandwidth on links close to some senders will be
greater than what is required. This restricts the applicability of
WF for traffic engineering purposes.
Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE
objects cannot be used with WF reservations. As a result of this objects cannot be used with WF reservations. As a result of this
issue and the lack of applicability to traffic engineering, use of WF issue and the lack of applicability to traffic engineering, use of WF
is not considered in this document. is not considered in this document.
2.4.3. Shared Explicit (SE) Style 2.4.3. Shared Explicit (SE) Style
The Shared Explicit (SE) style allows a receiver to explicitly The Shared Explicit (SE) style allows a receiver to explicitly
specify the senders to be included in a reservation. There is a specify the senders to be included in a reservation. There is a
skipping to change at page 14, line 34 skipping to change at page 14, line 34
The format of the Resv message is as follows: The format of the Resv message is as follows:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list> <flow descriptor list> ::= <FF flow descriptor list>
| <SE filter spec list | <SE flow descriptor>
<FF flow descriptor list> ::= <FF flow descriptor> <FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list> <FF flow descriptor> | <FF flow descriptor list> <FF flow
descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL> <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec> <SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec> | <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] <SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
skipping to change at page 20, line 39 skipping to change at page 20, line 39
include a LABEL object in Resv messages pertaining to that Path include a LABEL object in Resv messages pertaining to that Path
message. If a LABEL_REQUEST object was not present in the Path message. If a LABEL_REQUEST object was not present in the Path
message, a node MUST NOT include a LABEL object in a Resv message for message, a node MUST NOT include a LABEL object in a Resv message for
that Path message's session and PHOP. that Path message's session and PHOP.
A node that sends a LABEL_REQUEST object must be ready to accept and A node that sends a LABEL_REQUEST object must be ready to accept and
correctly process a LABEL object in the corresponding Resv messages. correctly process a LABEL object in the corresponding Resv messages.
A node that recognizes a LABEL_REQUEST object, but that is unable to A node that recognizes a LABEL_REQUEST object, but that is unable to
support it (possibly because of a failure to allocate labels) should support it (possibly because of a failure to allocate labels) should
send a PathErr with the error code "Routing problem" and the subcode send a PathErr with the error code "Routing problem" and the error
"MPLS label allocation failure." This includes the case where a value "MPLS label allocation failure." This includes the case where
label range has been specified and a label cannot be allocated from a label range has been specified and a label cannot be allocated from
that range. that range.
If the receiver cannot support the protocol L3PID, it should send a If the receiver cannot support the protocol L3PID, it should send a
PathErr with the error code "Routing problem" and the subcode PathErr with the error code "Routing problem" and the error value
"Unsupported L3PID." This causes the RSVP session to fail. "Unsupported L3PID." This causes the RSVP session to fail.
4.2.2. Non-support of the Label Request Object 4.2.2. Non-support of the Label Request Object
An RSVP router that does not recognize the LABEL_REQUEST object sends An RSVP router that does not recognize the LABEL_REQUEST object sends
a PathErr with the error code "Unknown object class" toward the a PathErr with the error code "Unknown object class" toward the
sender. An RSVP router that recognizes the LABEL_REQUEST object but sender. An RSVP router that recognizes the LABEL_REQUEST object but
does not recognize the C_Type send a PathErr with the error code does not recognize the C_Type send a PathErr with the error code
"Unknown object C_Type" toward the sender. This causes the path "Unknown object C_Type" toward the sender. This causes the path
setup to fail. The sender should notify management that a LSP cannot setup to fail. The sender should notify management that a LSP cannot
be established and possibly take action to continue the reservation be established and possibly take action to continue the reservation
without the LABEL_REQUEST. without the LABEL_REQUEST.
RSVP is designed to cope gracefully with non-RSVP routers anywhere RSVP is designed to cope gracefully with non-RSVP routers anywhere
between senders and receivers. However, obviously, non-RSVP routers between senders and receivers. However, obviously, non-RSVP routers
cannot convey labels via RSVP. This means that if a router has a cannot convey labels via RSVP. This means that if a router has a
neighbor that is not RSVP capable, the router must not advertise the neighbor that is known to not be RSVP capable, the router must not
LABEL_REQUEST object when sending messages that pass through the advertise the LABEL_REQUEST object when sending messages that pass
non-RSVP routers. The router should send a PathErr back to the through the non-RSVP routers. The router should send a PathErr back
sender, with the error code "Routing problem" and the subcode "MPLS to the sender, with the error code "Routing problem" and the error
being negotiated, but a non-RSVP capable router stands in the path." value "MPLS being negotiated, but a non-RSVP capable router stands in
See [1] for a description of how routers can determine the presence the path." This same message should be sent, if a router receives a
of non-RSVP routers. LABEL_REQUEST object in a message from a non-RSVP See [1] for a
description of how a downstream router can determine the presence of
non-RSVP routers.
4.3. Explicit Route Object 4.3. Explicit Route Object
As stated earlier, explicit routes are to be specified through a new As stated earlier, explicit routes are to be specified through a new
EXPLICIT_ROUTE object (ERO) in RSVP Path messages. The EXPLICIT_ROUTE object (ERO) in RSVP Path messages. The
EXPLICIT_ROUTE object has the following format: EXPLICIT_ROUTE object has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 17 skipping to change at page 22, line 22
4.3.1. Applicability 4.3.1. Applicability
The EXPLICIT_ROUTE object is intended to be used only for unicast The EXPLICIT_ROUTE object is intended to be used only for unicast
situations. Applications of explicit routing to multicast are a situations. Applications of explicit routing to multicast are a
topic for further research. topic for further research.
The EXPLICIT_ROUTE object is to be used only when all routers along The EXPLICIT_ROUTE object is to be used only when all routers along
the explicit route support RSVP and the EXPLICIT_ROUTE object. The the explicit route support RSVP and the EXPLICIT_ROUTE object. The
EXPLICIT_ROUTE object is assigned a class value of the form 0bbbbbbb. EXPLICIT_ROUTE object is assigned a class value of the form 0bbbbbbb.
RSVP routers that do not support the object will therefor response RSVP routers that do not support the object will therefore response
with an "Unknown Object Class" error. with an "Unknown Object Class" error.
4.3.2. Semantics of the Explicit Route Object 4.3.2. Semantics of the Explicit Route Object
An explicit route is a particular path in the network topology. An explicit route is a particular path in the network topology.
Typically, the explicit route is determined by a node, with the Typically, the explicit route is determined by a node, with the
intent of directing traffic along that path. intent of directing traffic along that path.
An explicit route is described as a list of groups of nodes along the An explicit route is described as a list of groups of nodes along the
explicit route. Certain operations to be performed along the path explicit route. Certain operations to be performed along the path
skipping to change at page 33, line 12 skipping to change at page 33, line 25
router, the router stores a copy of it in the Path State Block. The router, the router stores a copy of it in the Path State Block. The
RRO is then used in the next Path refresh event for formatting Path RRO is then used in the next Path refresh event for formatting Path
messages. When a new Path message is to be sent, the router adds a messages. When a new Path message is to be sent, the router adds a
new subobject to the RRO and appends the resulting RRO to the Path new subobject to the RRO and appends the resulting RRO to the Path
message before transmission. message before transmission.
The newly added subobject must be this router's IP address. The The newly added subobject must be this router's IP address. The
address to be added should be the interface address of the outgoing address to be added should be the interface address of the outgoing
Path messages. If there are multiple addresses to choose from, the Path messages. If there are multiple addresses to choose from, the
decision is a local matter. However, it is recommended that the same decision is a local matter. However, it is recommended that the same
address be chosen consistently. If the newly added subobject causes address be chosen consistently.
the RRO to be too big to fit in a Path message, the Path message
shall be dropped and a PathErr message should be sent back to the If the newly added subobject causes the RRO to be too big to fit in a
sender. Path (or Resv) message, the RRO object shall be dropped from the
message and message processing continues as normal. A PathErr (or
ResvErr) message should be sent back to the sender (or receiver). An
error code of "Notify" and an error value of "RRO too large for MTU"
is used. The RRO object is included in the error message. If the
receiver receives such a ResvErr, it should send a PathErr message
with error code of "Notify" and an error value of "RRO notification".
The RRO object is included in the error message.
A sender receiving either of these error values should remove the RRO
from the Path message.
Nodes should resend the above PathErr or ResvErr message each n
seconds where n is the greater of 15 and the refresh interval for the
associated Path or RESV message. The node may apply limits and/or
back-off timers to limit the number of messages sent.
An RSVP router can decide to send Path messages before its refresh An RSVP router can decide to send Path messages before its refresh
time if the RRO in the next Path message is different from the time if the RRO in the next Path message is different from the
previous one. This can happen if the contents of the RRO received previous one. This can happen if the contents of the RRO received
from the previous hop router changes or if this RRO is newly added to from the previous hop router changes or if this RRO is newly added to
(or deleted from) the Path message. (or deleted from) the Path message.
When the destination node of an RSVP session receives a Path message When the destination node of an RSVP session receives a Path message
with an RRO, this indicates that the sender node needs route with an RRO, this indicates that the sender node needs route
recording. The destination node initiates the RRO process by adding recording. The destination node initiates the RRO process by adding
skipping to change at page 34, line 14 skipping to change at page 34, line 42
class is the transient loop, which occurs as a normal part of class is the transient loop, which occurs as a normal part of
operations as L3 routing tries to converge on a consistent forwarding operations as L3 routing tries to converge on a consistent forwarding
path for all destinations. The second class of forwarding loop is path for all destinations. The second class of forwarding loop is
the permanent loop, which normally results from network mis- the permanent loop, which normally results from network mis-
configuration. configuration.
The action performed by a node on receipt of an RRO depends on the The action performed by a node on receipt of an RRO depends on the
message type in which the RRO is received. message type in which the RRO is received.
For Path messages containing a forwarding loop, the router builds and For Path messages containing a forwarding loop, the router builds and
sends a "Routing problem" PathErr message, with the subcode "loop sends a "Routing problem" PathErr message, with the error value "loop
detected," and drops the Path message. Until the loop is eliminated, detected," and drops the Path message. Until the loop is eliminated,
this session is not suitable for forwarding data packets. How the this session is not suitable for forwarding data packets. How the
loop eliminated is beyond the scope of this document. loop eliminated is beyond the scope of this document.
For Resv messages containing a forwarding loop, the router simply For Resv messages containing a forwarding loop, the router simply
drops the message. Resv messages should not loop if Path messages do drops the message. Resv messages should not loop if Path messages do
not loop. not loop.
4.4.5. Non-support of RRO 4.4.5. Non-support of RRO
The RRO object is to be used only when all routers along the path The RRO object is to be used only when all routers along the path
support RSVP and the RRO object. The RRO object is assigned a class support RSVP and the RRO object. The RRO object is assigned a class
value of the form 0bbbbbbb. RSVP routers that do not support the value of the form 0bbbbbbb. RSVP routers that do not support the
object will therefor response with an "Unknown Object Class" error. object will therefore response with an "Unknown Object Class" error.
4.5. Error Subcodes for ERO and RRO 4.5. Error Codes for ERO and RRO
In the processing described above, certain errors must be reported as In the processing described above, certain errors must be reported as
part of a "Routing Problem" PathErr message. The value of the either a "Routing Problem" or "Notify". The value of the "Routing
"Routing Problem" error code is 24 (TBD). Problem" error code is 24 (TBD); the value of the "Notify" error code
is 25 (TBD).
The following defines the subcodes for the routing problem PathErr The following defines error values for the Routing Problem Error
message: Code:
Value Error: Value Error:
1 Bad EXPLICIT_ROUTE object 1 Bad EXPLICIT_ROUTE object
2 Bad strict node 2 Bad strict node
3 Bad loose node 3 Bad loose node
4 Bad initial subobject 4 Bad initial subobject
skipping to change at page 35, line 30 skipping to change at page 36, line 4
6 RRO syntax error detected 6 RRO syntax error detected
7 RRO indicated routing loops 7 RRO indicated routing loops
8 MPLS being negotiated, but a non-RSVP-capable router 8 MPLS being negotiated, but a non-RSVP-capable router
stands in the path stands in the path
9 MPLS label allocation failure 9 MPLS label allocation failure
10 Unsupported L3PID 10 Unsupported L3PID
For the Notify Error Code, the 16 bits of the Error Value field are:
ss00 cccc cccc cccc
The high order bits are as defined under Error Code 1. (See [1]).
When ss = 00, the following subcode is defined:
1 RRO too large for MTU
2 RRO notification
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. The LSP_TUNNEL_IPv4 objects have the following FILTER_SPEC objects. The LSP_TUNNEL_IPv4 objects have the following
format: format:
4.6.1. Session Object 4.6.1. Session Object
Class = SESSION, C-Type = LSP_TUNNEL_IPv4 (7) Class = SESSION, C-Type = LSP_TUNNEL_IPv4 (7)
skipping to change at page 41, line 11 skipping to change at page 41, line 38
displayable characters. The Length must always be a multiple of 4 displayable characters. The Length must always be a multiple of 4
and must be at least 8. For an object length that is not a multiple and must be at least 8. For an object length that is not a multiple
of 4, the object is padded with trailing NULL characters. The Name of 4, the object is padded with trailing NULL characters. The Name
Length field contains the actual string length. Length field contains the actual string length.
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. Flowspec Object for Class-of-Service Service 4.8. Tspec and Flowspec Object for Class-of-Service Service
An LSP may not need bandwidth reservations or QoS guarantees. Such 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 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 for setting up LSPs. When resources do not have to be allocated to
the LSP, the Class-of-Service service should be used. the LSP, the Class-of-Service service should be used.
The Class-of-Service FLOWSPEC allows indication of a Class of Service The Class-of-Service FLOWSPEC allows indication of a Class of Service
(CoS) value that should be used when handling data packets associated (CoS) value that should be used when handling data packets associated
with the request. with the request.
The format of the Class-of-Service FLOWSPEC object is: The same format is used both for SENDER_TSPEC object and FLOWSPEC
objects. The formats are:
Class-of-Service flowspec object: Class = 9, C-Type = 3 (TBA) Class-of-Service SENDER_TSPEC object: Class = 12, C-Type = 3 (TBA)
Class-of-Service FLOWSPEC object: Class = 9, C-Type = 3 (TBA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CoS | Maximum Packet Size [M] | | Reserved | CoS | Maximum Packet Size [M] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Reserved
This field is reserved. It must be set to zero on transmission This field is reserved. It must be set to zero on transmission
skipping to change at page 41, line 48 skipping to change at page 42, line 32
Indicates the Class of Service (CoS) of the data traffic Indicates the Class of Service (CoS) of the data traffic
associated with the request. A value of zero (0) indicates associated with the request. A value of zero (0) indicates
that associated traffic is "Best-Effort". Specifically no that associated traffic is "Best-Effort". Specifically no
service assurances are being requested from the network. The service assurances are being requested from the network. The
intent is to enable networks to support the IP ToS Octet as intent is to enable networks to support the IP ToS Octet as
defined in RFC1349 [7]. It is noted that there is ongoing work 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 within the IETF to update the use of the IP ToS Octet. In
particular, RFC2474 [8], obsoletes RFC1349. However at this particular, RFC2474 [8], obsoletes RFC1349. However at this
time the new uses of this field (now termed the DS byte) are time the new uses of this field (now termed the DS byte) are
still being defined. still being defined. Non-zero values have local significance.
The translation from a specific value to an allocation is a
local administrative decision.
M M
The maximum packet size parameter [M] should be set to the The maximum packet size parameter [M] should be set to the
value of the smallest path MTU. This parameter is set in Resv value of the smallest path MTU. This parameter is set in Resv
messages by the reliever based on information in arriving RSVP messages by the reliever based on information in arriving RSVP
ADSPEC objects. This parameter is ignored when the object is ADSPEC objects. This parameter is ignored when the object is
contained in Path messages. contained in Path messages.
5. Acknowledgments 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. Security Considerations
In principle these extensions to RSVP pose no security exposures over
and above RFC 2205[1]. However, there is a slight change in the
trust model. Traffic sent on a normal RSVP session can be filtered
according to source and destination addresses as well as port
numbers. In this specification, filtering occurs only on the basis
of an incoming label. For this reason an administration may which to
limit the domain over which LSP tunnels can be established. This can
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). In such a case an implementation MAY generate a Path_Err
message with an error code of 02, "Policy Control failure".
6. Intellectual Property Considerations
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.
7. 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
previous Internet Drafts. The authors of the current draft wish to previous Internet Drafts. The authors of the current draft wish to
thank the authors of those drafts. They are Steven Blake, Bruce thank the authors of those drafts. They are Steven Blake, Bruce
Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun
Viswanathan. We also wish to thank Bora Akyol, Yoram Bernet and Alex Viswanathan. We also wish to thank Bora Akyol, Yoram Bernet and Alex
Mondrus for their comments on this draft. Mondrus for their comments on this draft.
6. References 8. References
[1] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- [1] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205, September 1997. Version 1, Functional Specification", RFC 2205, September 1997.
[2] Rosen, E. et al., "Multiprotocol Label Switching Architeture", [2] Rosen, E. et al., "Multiprotocol Label Switching Architeture",
Internet Draft, draft-ietf-mpls-arch-04.txt, February 1999. Internet Draft, draft-ietf-mpls-arch-04.txt, February 1999.
[3] Awduche, D. et al., "Requirements for Traffic Engineering over [3] Awduche, D. et al., "Requirements for Traffic Engineering over
MPLS", MPLS",
Internet Draft, draft-ietf-mpls-traffic-eng-00.txt, October 1998. Internet Draft, draft-ietf-mpls-traffic-eng-00.txt, October 1998.
skipping to change at page 43, line 5 skipping to change at page 45, line 5
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[7] Almquist, P., "Type of Service in the Internet Protocol Suite", [7] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992. RFC 1349, July 1992.
[8] Nichols, K. et al., "Definition of the Differentiated Services Field [8] Nichols, K. et al., "Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
7. Authors' Addresses 9. Authors' Addresses
Daniel O. Awduche Daniel O. Awduche
UUNET Worldcom UUNET (MCI Worldcom), Inc
3060 Williams Drive 3060 Williams Drive
Fairfax, VA 22031 Fairfax, VA 22031
Voice: +1 703 208 5277 Voice: +1 703 208 5277
Email: awduche@uu.net Email: awduche@uu.net
Lou Berger Lou Berger
FORE Systems LabN Consulting
1595 Spring Hill Road, Suite 500 Voice: +1 301 468 9228
Vienna, VA 22182 Email: lberger@labn.net
Voice: +1 703 245 4527
Email: lberger@fore.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 Voice: +1 650 526
Email: dhg@juniper.net Email: dhg@juniper.net
Tony Li Tony Li
Juniper Networks, Inc. Procket Networks
385 Ravendale Drive 3910 Freedom Circle, Ste. 102A
Mountain View, CA 94043 Santa Clara CA 95054
Voice: +1 650 526 8006 Email: tony1@home.net
Email: tli@juniper.net
Vijay Srinivasan Vijay Srinivasan
Torrent Networking Technologies Corp. Torrent Networking Technologies Corp.
3000 Aerial Center Parkway, Suite 140 3000 Aerial Center Parkway, Suite 140
Morrisville, NC 27560 Morrisville, NC 27560
Voice: +1 919 468 8466 ext. 236 Voice: +1 919 468 8466 ext. 236
Email: vijay@torrentnet.com Email: vijay@torrentnet.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 

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