INTERNET DRAFT S. Ganti
Internet Engineering Task Force N. Seddigh
Differentiated Services Working Group B. Nandy
Expires September, 2001 Tropic Networks
April, 2001
MPLS Support of Differentiated Services using E-LSP
<draft-ganti-mpls-diffserv-elsp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Abstract
There are currently two types of LSPs that can be used to support
Diff-serv over MPLS [DIFF-MPLS]: E-LSPs and L-LSPs. This document
defines extensions relating to the use of E-LSPs in an MPLS network.
The E-LSP approach allows multiple Ordered Aggregates (OAs) to be
carried by a single LSP. The existing E-LSP specification only
supports collective bandwidth signalling for all the OAs in an E-LSP.
However, there exist uses of the E-LSP approach where it is desirable
to support bandwidth signalling on a per-OA or per-PSC basis. This
document extends the original E-LSP approach by defining extensions
to support per-OA signalling. The extensions are proposed for both
RSVP and CR-LDP.
1.0 Introduction
The current solutions to support Diffserv over MPLS [DIFF-MPLS]
define two types of LSPs. These are commonly referred to as E-LSPs
(Exp-inferred-LSPs) and L-LSPs (Label-Only-Inferred-LSPs). The L-LSP
Ganti, Seddigh, Nandy [Page 1]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
approach is intended to carry a single OA per LSP. E-LSPs allow
multiple OAs to be carried over a single LSP. In this case, the MPLS
Label-Stack-Entry EXP bits indicate the PHB to be applied against a
particular packet.
E-LSPs are particularly useful in a number of scenarios. Firstly,
from a network management perspective it may be easier to create
end-to-end services for a customer if a single LSP is used, instead
of setting up, maintaining, administering and monitoring multiple
LSPs (as in L-LSP) - one for each OA of the customer's traffic. Thus,
E-LSPs reduce the number of LSPs needed to deploy end-to-end services
in a network. In addition, path protection and switching mechanisms
are more easily applied to a single LSP than a group of related LSPs.
A third application of E-LSPs is to support bandwidth borrowing among
the OAs of a customer while restricting bandwidth borrowing between
customers.
The current RSVP-TE and Diffserv-MPLS extensions allow resources to
be reserved and signaled on a E-LSP traffic aggregate basis. However,
it is also desirable to facilitate a traffic engineering approach
where (i) resources are reserved and signaled on a per-OA basis
within an E-LSP (ii) EXP bits are used to signal the PHB treatment
for individual packets within the E-LSP (iii) Diffserv PHB mechanisms
are used in LSR routers to differentially treat the traffic within a
single E-LSP.
Such an approach would have two requirements: (i) IGP extensions to
advertise reserved or available bandwidth on a per-OA or PSC basis
for each link [BITAR] (ii) MPLS protocol extensions to signal traffic
profiles or bandwidth for the individual OAs carried on the E-LSP.
This document is concerned with the second requirement listed above.
The current E-LSP solution proposed in [DIFF-MPLS] does not address
per-OA signaling. It only supports signaling of bandwidth
requirements for the entire aggregate traffic on the E-LSP.
This document proposes RSVP-TE and CR-LDP extensions to facilitate
signaling of per-OA traffic profiles for E-LSPs. This document uses
the terms BA, OA, PSC, E-LSP, L-LSP, and PHB as they are defined in
[DIFF-MPLS] and [DIFFTERM].
2.0 Potential Solutions
2.1 Possible Solutions for RSVP-TE
To extend per-OA signaling of E-LSPs for RSVP, there are at least
three possible approaches. These are: 1) Creating a new E-LSP object,
2) Extending flowspec to signal Multiple FlowSpecs in a path message
and 3) Extending the existing DiffServ object [DIFF-MPLS] definition.
The first approach defines a new ELSP RSVP object to carry the
traffic profile parameters. This object must be present in both the
PATH and RESV messages. The second approach defines new SENDER_TSPEC
and FLOWSPEC object types (using a new C-Type) [RSVP] and allows
multiple such objects to be carried in the respective PATH and RESV
Ganti, Seddigh, Nandy [Page 2]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
messages. The third approach modifies and extends the specification
of the DIFFSERV object as defined in [DIFFSERV-MPLS]. In addition, it
requires this object to be present in both the PATH and RESV
messages.
2.2 Possible Solutions for CR-LDP
To extend per-OA signaling of E-LSPS for CR-LDP, there are at least
two possible approaches: (i) Define a new ELSP TLV (ii) Modify the
existing Traffic Parameters TLV. The first approach would simply
define a new optional TLV that would carry the per-OA traffic
parameters being signalled. In this approach, the new TLV could co-
exist with the old Traffic Parameter TLV which could be used to
signal traffic profiles for the entire E-LSP. The second approach
would require modifications to the CR-LDP specification to allow
multiple Traffic Parameter TLVs and would also require a modification
to the Traffic Parameter TLV itself.
2.3 Preferred Solution
For CR-LDP, the approach of defining a new optional ELSP TLV is the
preferred approach because it does not require any changes to the
existing Traffic Parameter TLV. Thus, implementations that do not
wish to signal per-OA traffic parameters can simply use the Traffic
Parameter TLV to signal per-LSP traffic parameters as is currently
the case.
For RSVP, the first approach of creating a new ELSP object will
ensure full backwards compatibility with previous definitions of
RSVP. The second approach of defining new object types for the
SENDER_TSPEC and FLOWSPEC objects warrants consideration as it reuses
an existing object by extending a new C-Type. These new objects can
also co-exist with a traditional SENDER_TSPEC and FLOWSPEC objects of
C-Type 1. However, there is a slight potential that it may break
existing RSVP implementations and in fact, the new object types have
slight differences with the old object types for SENDER_TSPEC and
FLOWSPEC. The third approach of modifying the proposed DIFFSERV
object [DIFF-MPLS] appears to be the least desirable. This last
approach would change the intended purpose of the DIFFSERV object,
would require significant modifications to the object and would
require the object to be present in the RESV message - something that
is not currently required.
Thus, the preferred approach to supporting per-OA signaling is to
specify a new ELSP object for RSVP and a new ELSP TLV for CR-LDP.
Such an approach would ensure a common solution for the two protocols
and appears to be the most likely way of ensuring backwards
compatibility with the existing protocol specification.
Subsequent sections define the proposed ELSP object and TLV for RSVP
and CR-LDP respectively. For completeness, the two alternative
solutions for RSVP extensions are captured in the Appendix. (These
solutions are described only for the sake of current reference and
may be deleted in future versions of this document.)
Ganti, Seddigh, Nandy [Page 3]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
3. RSVP Extensions To Support Per-OA signaling on E-LSPs
In this section we describe RSVP extensions to support signaling of
per-OA traffic profiles in an E-LSP. A single PATH/RESV message pair
is used to signal traffic profiles for all the OAs in an E-LSP. The
extensions specified in this section only relate to E-LSPs and do not
apply to L-LSPs.
3.1 ELSP Object Definition
To signal traffic profiles for multiple OAs in a single E-LSP, a new
ELSP object is defined. This object must be present in both the PATH
and RESV messages. E-LSPs that do not wish to signal traffic profiles
on a per-OA basis do not include this object. The ELSP object
specification is captured below.
ELSP Object:
class = TBD, C_Type = 1 (need to get an official class num from the
IANA with the form 0bbbbbbb)
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 | numTP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (numTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 28 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
numTP : 4 bits
Indicates the number of TrafficProfile entries included
in the E-LSP Object. This can be set to any
value from 0 to 8.
Each TP entry provides the Traffic Profile
associated with a PSC reservation for that E-LSP.
The TP entry has the following format:
Ganti, Seddigh, Nandy [Page 4]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The PSC is encoded as specified in [PHBID]. The traffic profile
parameters are the same as the basic Token Bucket parameters
originally defined for RSVP. Since this is a Diffserv enabled network
it is assumed that traffic profiles are only applied at the edge.
Thus, there is no need to convey the exact parameters used by the
marker at the domain edge. The parameters are signalled for admission
control purposes only.
If desired, the existing SENDER_TSPEC and FLOWSPEC objects MAY be
used to signal bandwidth requirements for the entire traffic
aggregate transmitted on an E-LSP. The ELSP specification does not
preclude this type of signaling.
3.2 Handling of ELSP Object
The ELSP object is optional with respect to RSVP.
To signal per-OA traffic profiles on an ELSP, a sender MUST include
the ELSP object in the PATH message. If the PATH message includes an
ELSP object, the receiver MUST insert an ELSP object in the RESV
message. The receiver MUST not include an ELSP object in the RESV
message if the PATH message did not include an ELSP object.
Each OA signaled in the ELSP object MUST have a corresponding set of
EXP<->PHB mappings that were either pre-configured or signaled via
the DIFFSERV object. If a node receives a PATH message with a ELSP
object containing one or more OA traffic profiles without existing
EXP<->PHB mappings, it should fail the reservation request for all
the signaled OAs. In this case, the node SHOULD generate a PATH_ERR
message with error value of 'Unsupported PSC'.
A TE solution seeking to use preconfigured EXP<->PHB mapping with
signaled per-OA traffic profiles would send a PATH message without
the DIFFSERV object but with the ELSP object.
A TE solution with signaled EXP<->PHB mapping and signaled per-OA
traffic profiles would send a PATH message with both the DIFFSERV and
ELSP objects. The DIFFSERV object should include a corresponding
Ganti, Seddigh, Nandy [Page 5]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
entry for each signaled OA in the ELSP object.
A sender SHOULD not include an ELSP object with 0 TP entries in the
PATH message. Such an object SHOULD be ignored by intermediate LSRs
and the receiving LER.
A node that receives a PATH message with an ELSP object but which
does not support per-OA resource reservation SHOULD generate a
PATH_ERR message with error value: "Unsupported object".
If an LSR rejects a resource reservation for a particular OA signaled
in an ELSP, it SHOULD consider the resource reservation to have
failed for the entire ELSP. In this case, it SHOULD generate a
RESV_ERR message with error value "Admission Control Failure for an
OA".
3.3 RSVP Error Codes Related to the ELSP Object
The errors described in the previous section should be reported with
the error code for an 'ELSP Error' - this code is to be allocated by
IANA.
The following error values are valid for the 'ELSP Error' error code:
Value Error
----- -----
1 Admission Control Failure for an OA
2 Unsupported ELSP Object
3 Unsupported PSC for per-OA signaled E-LSP
4.0 LDP Extensions
The [DIFF-MPLS] draft extended the LDP messages by defining a new
Diff-Serv TLV. This draft introduces a new optional TLV called ELSP
TLV for the purpose of per-OA signaling with E-LSPs. The TLV is
intended to be used only with E-LSPs and not with L-LSPs.
The ELSP TLV is optional with respect to LDP. Handling of the Diff-
Serv TLV should follow the rules specified in [DIFF-MPLS]. It is
expected that for each OA signaled in the ELSP TLV there will be a
corresponding set of EXP<->PHB mappings that were either pre-
configured or signaled via the DIFFSERV TLV.
4.1 ELSP TLV
The ELSP TLV has the following format:
Ganti, Seddigh, Nandy [Page 6]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| ELSP (0x910) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | numTP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (numTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 28 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
numTP : 4 bits
Indicates the number of TrafficProfile entries included
in the ELSP TLV. This can be set to any value from 0 to 8.
TP entry:
Each TP entry provides the Traffic Profile
associated with a PSC reservation for that E-LSP.
The TP entry has the following format (similar to Traffic
parameters TLV of [CR-LDP]):
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 | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Frequency | Reserved | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate (PDR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Burst Size (PBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Data Rate (CDR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Burst Size (EBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PSC is encoded as specified in [PHBID]. The remaining parameters
are as specified in the traffic parameters TLV of CR-LDP [CR-LDP].
4.2 LDP Messages
The Label Request, Label Mapping and Notification messages are
Ganti, Seddigh, Nandy [Page 7]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
extended to optionally contain the ELSP TLV. In addition, new status
codes are defined in the status code field of the Status TLV.
4.3 Handling of the ELSP TLV
4.3.1 Handling of the ELSP TLV in Downstream Unsolicited Mode
The ELSP TLV is only meaningful in Downstream on Demand mode and so
should not be used with Downstream Unsolicited mode
4.3.2 Handling of the ELSP TLV in Downstream on Demand Mode
This section describes operations when the Downstream on Demand Mode
is used. The ELSP TLV should be used only if the EXP<->PHB mapping is
either pre-configured or signaled via the DIFFSERV TLV.
An upstream LSR seeking to use preconfigured EXP<-->PHB mapping and
signaled per-OA traffic profiles, would send a Label Request message
without the Diff-Serv TLV, but with an ELSP TLV.
An upstream LSR seeking to use signaled EXP<-->PHB mapping and
signaled per-OA traffic profiles, would send a Label Request message
with both the Diff-Serv and ELSP TLVs included. The DIFFSERV TLV
should include one MAP entry for each corresponding traffic profile
signalled via the ELSP TLV.
A downstream Diff-Serv LSR sending a Label Mapping message in
response to a Label Request message for an E-LSP should include the
ELSP TLV.
A downstream Diff-Serv LSR receiving a Label Request message with the
ELSP TLV for an E-LSP containing a PSC value which is not supported,
must reject the request by sending a Notification message which
includes the Status TLV with a Status Code of `Unsupported PSC'.
A downstream Diff-Serv LSR that recognizes the ELSP TLV Type in a
Label Request message but is unable to grant the reservation request
for one of the OAs signaled in the ELSP TLV, must reject the entire
request and send a Notification message which includes the Status TLV
with a Status Code of `Resource Unavailable for an OA reservation
request'.
A downstream Diff-Serv LSR that recognizes the ELSP TLV Type in a
Label Request message and supports the requested PSC but is not able
to satisfy the label request for other reasons (e.g. no label
available), must send a Notification message in accordance with
existing LDP procedures [LDP] (e.g. with a `No Label Resource' Status
Code). This Notification message must include the requested ELSP TLV.
4.4 Non-Handling of the ELSP TLV
An LSR that does not recognize the ELSP TLV Type, on receipt of a
Label Request message or a Label Mapping message containing the ELSP
Ganti, Seddigh, Nandy [Page 8]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
TLV, must behave in accordance with the procedures specified in [LDP]
for an unknown TLV whose U Bit and F Bit are set to 0 i.e. it must
ignore the message, return a Notification message with `Unknown TLV'
Status.
4.5 E-LSP Status Code Values
The following values are defined for the Status Code field of the
Status TLV:
Status Code E Status Data
Unexpected ELSP TLV 0 0x01000010
Unsupported PSC 0 0x01000011
Resource Unavailable for an OA resv req 0 0x01000012
5.0 Security Considerations
This document does not introduce any new security issues beyond those
inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms
proposed for those technologies.
6.0 References
[BITAR] Bitar N et al, "Traffic Engineering Extensions to OSPF",
Internet Draft, <draft-bitar-rao-diffserv-mpls-00.txt>,
July 2000
[RSVP] Braden et al, "Resource Reservation Protocol - Version 1
Functional Specification", RFC 2205, September 1997
[INTSERV] Wroclawski J, "Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997
[INTCHAR] Shenker S et al, "General Characterization Parameters for
Integrated Services Network Elements", RFC 2215,
September 1997
[DIFF-MPLS] Rosen E et al, "MPLS Support of Differentiated Services"
draft-ietf-mpls-diff-ext-08.txt, February 2001.
[DIFFTERM] Grossman D, "New Terminology for Diffserv", Internet
Draft, draft-ietf-diffserv-new-terms-04.txt, March 2001
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", Internet draft,
<draft-ietf-mpls-rsvp-lsp-tunnel-08.txt>, February 2001
[CR-LDP] Jamoussi et al, "Constraint-Based LSP Setup using LDP",
Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
February 2001.
[PHBID] Brim S et al, "Per Hop Behaviour Identification Code",
RFC 2836, May 2000.
Ganti, Seddigh, Nandy [Page 9]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
7.0 Author's Address
Sudhakar Ganti
Tropic Networks Inc.
135 Michael Cowpland Drive
Kanata, Ontario, Canada, K2M 2E9
Email: sganti@tropicnetworks.com
Nabil Seddigh
Tropic Networks Inc.
135 Michael Cowpland Drive
Kanata, Ontario, Canada, K2M 2E9
Email: nseddigh@tropicnetworks.com
Biswajit Nandy
Tropic Networks Inc.
135 Michael Cowpland Drive
Kanata, Ontario, Canada, K2M 2E9
Email: bnandy@tropicnetworks.com
A.0 Appendix: Other approaches to signal E-LSP
This appendix captures the two other ways in which RSVP can be
extended to support per-OA signaling for E-LSPs. The approaches are
described below.
A.1 First Approach - New object type for FLOWSPEC & SENDER_TSPEC
Objects
In this second approach to signaling multiple OAs on single E-LSP, we
propose an extension to the FLOWSPEC and SENDER_TSPEC objects.
Specifically, new object types (C-Type) are defined for both of these
objects. Thus, a PATH message would have one such new SENDER_TSPEC
object per OA for which it wishes to signal bandwidth requirements.
Conversely, a RESV message would have one such new FLOWSPEC object
per OA for which bandwidth is being signaled. The PATH and RESV
messages can still use a single SENDER_TSPEC and FLOWSPEC object with
Intserv C-Type to signal the bandwidth requirement for the entire
traffic aggregate of this E-LSP. Such an object will be relevant to
admission control for the entire aggregate and will not be related to
a specific PSC, PHB or OA.
A description of the new SENDER_TSPEC and FLOWSPEC types is given
below.
New Object Type for FLOWSPEC
FLOWSPEC class = 9.
o Reserved (obsolete) flowspec object: Class = 9, C-Type = 1
o Int-serv Flowspec object: Class = 9, C-Type = 2
o E-LSP Per PSC Flowspec object: Class=9; C-Type=3
Ganti, Seddigh, Nandy [Page 10]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | (c) | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - PSC - Indicates the PHB Scheduling Class the traffic
profile applies to; Encoding as specified in
[PHBID]
(d) - Length of service 1 data, 6 words not including header
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including header
Essentially, the above data structure is similar to the original Intserv
FLOWSPEC object except that the service field is replaced
with the PSC field.
New Object Type for SENDER_TSPEC
SENDER_TSPEC class = 12
o Intserv Sender_Tspec object: Class = 9, C-Type = 2
o E-LSP Per PSC Sender_Tspec object: Class=9; C-Type=3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | (c) | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
Ganti, Seddigh, Nandy [Page 11]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - PSC - Indicates the PHB Scheduling Class the traffic
profile applies to; Encoding as specified in
[PHBID]
(d) - Length of service 1 data, 6 words not including header
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including header
Essentially, the above data structure is similar to the original
Intserv SENDER_TSPEC object except that the service field is replaced
with the PSC field.
A.2 Third Approach - Modifying the DIFFSERV object
The third approach to signal bandwidth requirements for multiple OAs
in a single E-LSP relies on extensions to the DIFFSERV object.
Currently, the DIFFSERV object specifies mapping between EXP bits and
PHBs. We extend it to specify traffic profiles on a per PSC basis.
Flexibility occurs because the solution allows for support of
multiple configuration options as described in [DIFFSERV-MPLS]. In
addition, where desired, the DIFFSERV object will contain a number of
entries to indicate the traffic profiles on a per-PSC basis.
The only other requirement is that when signaling per-OA bandwidth
requirements, the DIFFSERV object must be included in both the PATH
and the RESV message.
As with the previous two approaches, the SENDER_TSPEC and FLOWSPEC
objects can still be used to signal the bandwidth requirements for
the entire aggregate E-LSP traffic.
This section describes the changes to the <DIFFSERV> object of an E-
LSP [Diff-MPLS]. All the message formats or other object definitions
remain the same.
The DIFFSERV object formats are shown below. Currently there are two
possible C_Types. Type 1 is a DIFFSERV object for an E-LSP. Type 2 is
a DIFFSERV object for an L-LSP.
DIFFSERV object for an E-LSP:
class = TBD, C_Type = 1 (need to get an official class num from the
IANA with the form 0bbbbbbb)
Ganti, Seddigh, Nandy [Page 12]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
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 | nTP | nb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (nTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 26 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
nb : 4 bits
Indicates the number of MAP entries included in the DIFFSERV
Object. This can be set to any value from 0 to 8.
nTP: 4 bits
Indicates the number of Traffic Profile entries (each Traffic
Profile signals the bandwidth requirement for an OA.
MAP : 32 bits
The MAP entry remains as defined in [MPLS-DIFFSERV].
TP : 256 bits
The format of each TP is as follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | (c) | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
Ganti, Seddigh, Nandy [Page 13]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-00.txt September 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - PSC - Indicates the PHB Scheduling Class the traffic
profile applies to; Encoding as specified in
[PHBID]
(d) - Length of service 1 data, 6 words not including header
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including header
Ganti, Seddigh, Nandy [Page 14]