INTERNET DRAFT S. Ganti
Internet Engineering Task Force N. Seddigh
Differentiated Services Working Group B. Nandy
Expires December, 2002 Tropic Networks
June, 2002
MPLS Support of Differentiated Services using E-LSP
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
The current DS-TE (Diffserv Traffic Engineering) approach can only be
used with a single OA (Ordered Aggregate) per E-LSP or with L-LSP. It
cannot be used to carry multiple OAs per E-LSP.
This document motivates reasons where it is desirable to carry
multiple OAs per E-LSP. In addition, the document proposes RSVP-TE
and CR-LDP extensions to facilitate signalling of multiple traffic
parameters for a single E-LSP.
ID Summary
Ganti, Seddigh, Nandy [Page 1]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
SUMMARY
This document addresses an open issue in providing Diffserv Traffic
Engineering solution using E-LSP. The proposal outlines methods to
signal bandwidth requirements for multiple OAs when setting up E-
LSPs.
RELATED DOCUMENTS
draft-ietf-tewg-diff-te-reqts-04.txt
draft-bitar-rao-diffserv-mpls-01.txt
draft-ietf-tewg-diff-te-proto-00.txt
WHERE DOES IT FIT IN THE PICTURE OF SUB-IP WORK
It belongs in the TE WG
WHY IS IT TARGETED AT THIS WG
This document describes Diffserv Traffic Engineering possibilities
using E-LSP.
JUSTIFICATION
Current Diffserv Traffic Engineering solutions are restricted to L-
LSP or E-LSPs which carry only a single Ordered Aggregate (OA).
There is a clear need to extend these DS-TE solutions to include
carrying of multiple OAs per E-LSP. This document proposes possible
alternatives to address this.
1.0 Introduction
Diffserv over MPLS [DIFF-MPLS] describes methods to setup diffserv-
aware traffic engineering tunnels in an MPLS network. The solution
approaches discussed in [DIFF-MPLS] use two types of LSPs to setup
the TE tunnels. These are commonly referred to as E-LSPs (EXP-
inferred-LSPs) and L-LSPs (Label-Only-Inferred-LSPs). The L-LSP
approach is intended to carry a single OA per LSP. E-LSPs allow
multiple OAs to be carried over a single LSP. In the latter case, the
MPLS Label-Stack-Entry EXP bits indicate the PHB (Per Hop Behavior)
to be applied against a particular packet.
There have been recent efforts to enhance the existing Traffic
Engineering standards to support a Diffserv-based approach which
provides multiple classes of service. The requirements for this
approach are outlined in [DS-TE-REQ].
Ganti, Seddigh, Nandy [Page 2]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
Based on [DS-TE-REQ], protocol solutions have been proposed in [DS-
CT]. The proposed solution outlines mechanisms to support carrying of
a single OA per LSP. The solution also allows the carrying of
multiple OAs on an E-LSP. However, all such OAs will be treated as a
single Class Type. This is a limitation of [DS-CT]. Essentially, the
current solution is designed to support per-class routing. i.e the
case where different classes of traffic for a single user are sent
over different LSPs in a DS-TE enabled network.
This draft: (i) motivates the need for supporting multiple OAs on an
E-LSP in a DS-TE network (ii) Proposes RSVP-TE and CR-LDP extensions
to facilitate signaling of multiple per-OA traffic profiles on a
single E-LSP (iii) Shows how the extensions satisfy the requirements
and application scenarios outlined in [DS-TE-REQ].
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 The Need to support E-LSP based DS-TE with Multiple OAs
This document asserts that there is a viable requirement for
deploying complete E-LSP based DS-TE solutions. i.e a DS-TE solution
where multiple classes of traffic (OAs) are carried over a single
LSP. The E-LSP DS-TE solution should be complementary to L-LSP DS-TE
solutions. The following are examples where E-LSPs can be used in a
DS-TE framework to carry multiple OAs.
Example 1: VoIP data and signalling are carried on the same LSP but
treated as different classes. The easiest way of doing this is to
transport the data and signalling on different OAs in a single LSP.
It can be argued that if the ratio of two different traffic types is
known then it can be carried on multiple OAs but signalled with a
single traffic parameter and advertised with a single advertisement.
However, such a scheme is extremely inflexible. Applications
continually evolve as may the ratio of traffic mixes. Thus, it is
unwise to embed assumptions about application behaviour in the DS-TE
solutions.
Example 2: A key emerging application for E-LSPs with multiple OAs is
L2VPN. In this context, service providers in the Metro space are
looking to provide TLAN (Transparent LAN) services. The SP may
provide Layer 2 VPNs for its end customers where the key SLAs revolve
around availability and QoS. In such cases, the SLA may specify a
single protection level for the aggregate while specifying multiple
classes of service within the VPN. In such networks, sending
different classes of service on different LSPs will immensely
complicate the ability to offer robust and measurable availability
and QoS SLAs to such customers.
Ganti, Seddigh, Nandy [Page 3]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
Example 3: Path protection and restoration mechanisms are 2 key
requirements in next generation IP networks. Sending a single
customer's traffic on multiple LSPs causes a larger number of LSPs in
the network. It also causes issues with ensuring the 50ms restoration
time is met due to the sheer volume of LSPs that have to be
resignalled or redialed when links go down. These mechanisms are
more easily applied to a single LSP than to a group of LSPs.
Example 4: Earlier it was mentioned that service providers may want
to provide SLA gurantees for each of the OAs carried in the E-LSP. In
addition, at the same time, the provider may wish to apply queuing
technology that allows bandwidth borrowing between the OAs of a
customer. Thus, if a customer is not using his allocated AF
capacity, he may wish to allow his BE traffic to use that capacity
that he has purchased from the service provider.
Example 5: A small service provider with a simple network topology
and a limited set of service classes could be interested in limited
DS-TE capabilities (i.e. simple aggregate load balancing). In this
case, a simple path computation algorithm that routes all classes
together can be used to select a single LSP (e.g. a shortest path
applied on the pruned network). Limiting each LSP to only a single OA
would, at minimum, double the number of LSPs in the network - which
may be highly undesirable for the SP.
Example 6: Another key benefit of E-LSPs has to do with scalability.
L-LSP or single OA per E-LSP will cause the number of LSPs in the
network to increase by a factor of at least two and in some cases,
three, four or larger. The number of LSPs is a scalability concern
for a number of reasons. Firstly, it increases the time required
during hitless restart. Secondly, it is of concern for RSVP state
management.
Another important advantage of E-LSPs is in the area of network
maintenance and administration. When trouble-shooting issues related
to a customer's traffic, it is easier for the network operator to
examine a single LSP instead of multiple LSPs.
3.0 Requirements to support E-LSP based DS-TE with Multiple OAs
This section analyzes the requirements for an E-LSP DS-TE solution
with multiple OAs. The analysis is done in the context of the DS-TE
requirements as specified in [DS-TE-REQ].
3.1 DS-TE Compatibility
The first compatibility requirement in [DS-TE-REQ] specifies
interoperability with existing deployed TE mechanisms. The above
Ganti, Seddigh, Nandy [Page 4]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
requirement is satisfied by this draft. The deployed TE mechanisms
have no notion of class-types and thus, signal a single set of
traffic parameters using the defined objects in RSVP or CR-LDP.
Should there exist a network with some devices using the old TE
mechanisms and other devices upgraded to use the DS-TE solution in
this draft along with the necessary OSPF extensions, it is expected
that no interoperability issues should arise. For example, should an
RSVP signaling request wish to reserve bandwidth for an LSP without
indicating a CT, when that request passes through a DS-TE enabled
device, the device will recognize that there is only a single traffic
profile and will further recognize that this profile is signaled
using the pre-existing objects used to signal traffic parameters in
RSVP and CR-LDP. Similarly if an RSVP signaling request includes the
ELSP object and an LSR doesn't support this object, it will fail the
PATH setup and send a PATH_ERR back to the ingress LER. The head node
will then know that the ELSP object is not supported and can either
take another path or resignal without the ELSP object.
It should be mentioned that the scheme discussed in this draft will
also interoperate with the current solution in [DS-CT].
The second compability requirement in [DS-TE-REQ] specifies that DS-
TE deployment should be able to limit the required number of classes
in a network thus addressing scalability concerns with IGP
advertisements. This requirement is addressed in this draft by
mandating that the traffic profiles should be limitable based on the
number of class-types supported. i.e the protocol extensions should
not carry traffic profile for those class types that are not
supported.
3.2 Class-Type
The second requirement in [DS-TE-REQ] specifies that the DS-TE
solution must support traffic engineering based on different
constraints for different traffic trunks. Further, to deal with
scalability of available bandwidth advertisements using IGP, the
notion of class-types is introduced so that classes with similar
traffic requirements can be grouped in a class-type. Thus, the
available bandwidth (resources) advertisements (for a path
computation by head-end node) are done at the granularity of a CT and
the signalling protocol would also reserve bandwidth at the
granularity of a CT. For example, voice would constitute a first CT
and data a second CT.
A class could directly map to a PHB Scheduling class (PSC) while a CT
could be an aggregation of a few PSCs together for bandwidth
accounting and advertisement purposes.
Ganti, Seddigh, Nandy [Page 5]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
This E-LSP multiple OA DS-TE solution allows signaling of traffic
profiles per CT as per the requirements in section 3.2 of [DS-TE-
REQ].
In addition, while use of CT is one means of addressing scalability
issues, it comes at the cost of flexibility. Use of CT instead of
classes means that a provider is unable to route (or compute paths)
different classes of trafic on different LSPs should they wish to do
so, e.g. routing of AF1x and AF2x on separate LSPs. To handle this
case, the signalling extensions SHOULD allow signaling of per-PSC
traffic profiles instead of CT. The signaling extensions SHOULD not
mandate a mapping between PSC and CT. This mapping could be achieved
via configuration tables handled elsewhere in the system.
3.3 Bandwidth Constraints
[DS-TE-REQ] specifies that a solution MUST support a single default
bandwidth constraint model and allow support for up to 8 BCs. The DS-
TE E-LSP multiple OA solution allows the bandwidth constraint model
support and does not bring in any additional new requirements. Common
models such as the Russian Doll model or the Disjoint model (where
each CT has a reserved bandwidth and no other CT can borrow from this
value) are easily supportable with the DS-TE E-LSP multiple OA
solution.
3.4 Preemption and TE-Classes
In [DS-TE-REQ], it is mandated that the DS-TE solution should allow
the case where different LSPs have different pre-emption levels in a
network and also the case where all LSPs have the same pre-emption
levels in a network. Essentially, pre-emption and CT are recognized
to be orthogonal to each other. In order to accomodate the above,
[DS-TE-REQ] introduces the notion of TE-class. TE Class is defined
as a tuple <CT, pre-emption priority>. TE-classes are administrator
configured with one-to-one mapping between a TE-class and a CT, pre-
emption priority pair.
In E-LSP multiple-OA DS-TE, all the different OAs or Class-Types
carried on a "single E-LSP" MUST share the "same pre-emption
priority". Essentially it is not possible to derive the benefit of
aggregation of OAs along with the requirement for each OA to have a
different pre-emption level. A choice must be made. If the service
provider wishes to have different pre-emption levels, then separate
LSPs MUST be used to carry the traffic. Alternatively, if a service
provider does not require different pre-emption levels for an
aggregated set of CTs then a single E-LSP can be used to carry the
different CTs. This is particularly applicable for the traffic of a
single customer.
Ganti, Seddigh, Nandy [Page 6]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
Note that the [DS-TE-REQ] limits the number of pre-configured TE
Classes in a network to 8. This by necessity will imply that choices
have to be made regarding the number of CTs and pre-emption
priorities that can be supported. In [DS-CT] for example, if it is
desired to support two pre-emption priorities for all CTs then the
number of CTs is limited to 4.
The same is true for the multiple-OA E-LSP solution mandated in this
draft. For example, if it is desired to have a single pre-emption
level for all CTs then it is possible to support 8 TE classes. If it
is desired to support 2 pre-emption levels then a maximum of 4 CTs
can be defined.
3.5 Mapping of Traffic to LSPs
The [DS-TE-REQ] mandates that the DS-TE solution must support
operation of single OAs over E-LSP or L-LSP. Carrying a single OA per
E-LSP is a degenerate case of the solution in this document. If a
multiple OA E-LSP is setup, then the traffic belonging to all the OAs
of that LSP are carried using the same label but with different EXP
bit markings as per [DIFF-MPLS].
3.6 Dynamic Adjustment of Diffserv PHBs.
[DS-TE-ERQ] indicates that the DS-TE solution may support dynamic
adjustment of Diffserv PHB parameters based on the signalled traffic
profiles for the different CTs. Thus, the signaling of bandwidth
requirements for an LSP may cause an adjustment in t the scheduling
and buffer management parameters for scheduler queue.
This approach is supported in the solution provided in this draft. In
fact, because this draft also supports signalling of traffic
parameters on a per PSC basis, it can overcome one of the possible
deficiencies in a CT-based approach. For example, if AF1x and AF2x
traffic are aggregated and signalled as a single CT, a node will not
know how to accurately adjust the scheduling parameters for the two
different queues that AF1x and AF2x traffic map to. However, if the
MPLS protocol signals one traffic profile per PSC, each profile can
be mapped and used to modify the scheduling parameters of a unique
scheduler queue.
3.7 Overbooking
The multiple-OA DS-TE does not bring any new requirements in relation
to overbooking. It supports the same overbooking requirements as
described in [DS-TE-REQ]. It works with any IGP extensions that
signal overbooking factors. The MPLS path setup signaling extensions
Ganti, Seddigh, Nandy [Page 7]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
proposed in this document do not signal any form of overbooking
factors.
3.8 Restoration
The [DS-TE-REQ] document states that since standard restoration
mechanisms rely on pre-emption priority, the DS-TE solution should
ensure that it does not prevent such schemes.
The DS-TE E-LSP with multiple OA confirms to the above mentioned
requirement. If it is desired to have a different pre-emption
priority for different classes of traffic, then single OA can be sent
over an E-LSP. However, should it be desired to have the same pre-
emption priority for all the traffic classes of a single customer but
have different pre-emption priority for different customers, then
this can be accomodated using E-LSP with multiple OAs.
3.9 Technical Requirements & Solutions for E-LSP based DS-TE
It is desirable to facilitate an E-LSP DS-TE approach where (i)
resources are reserved and signaled on a per-OA basis (or per-class-
type, per-CT) 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. (iv) IGP extensions to advertise
reserved or available bandwidth on a per-OA, PSC or per-CT basis for
each link.
[BITAR] addresses requirement (iv) above. It proposes IGP protocol
extensions that allow OSPF to advertise TE information either on a
per-class or per-class-type basis. In addition, [DS-CT] also provides
IGP extensions to advertise per-CT bandwidth usage on network links.
Since this draft support signaling of either CT or PSC-based traffic
profiles, it will work with either of the above 2 IGP extensions.
However, there are some limitations to be aware of.
In [BITAR], the actual flooded information corresponds to PSCs and
groups of PSCs. The strength of this draft is its flexibility. Thus,
it allows advertisement of BW information for EF, AF1x, AF2x etc,
which can correspond to three different classes. At the same time,
it allows advertisement of aggregate BW information for EF, AF and
BE, which can correspond to 3 class types. In [DS-CT] the flooded IGP
packets correspond to CTs which have to be mapped to PSCs on a node.
This draft addresses (i) above. It proposes the carrying of multiple
traffic profiles - one per-PSC or per-CT depending on which approach
is selected. The current Diffserv-MPLS extensions allow only a
Ganti, Seddigh, Nandy [Page 8]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
single set of traffic parameters to be signalled per LSP. e.g in
RSVP-TE, it is allowable to signal only a single Tspec. To support E-
LSP, the signalling protocols need to be extended to allow
specification of multiple traffic parameters. Further, there needs to
be a means of mapping these traffic parameters to an OA, PSC or class
and class-type.
4.0 Potential Solutions
NOTE: This section is present to show the possibility of different
ways of providing multiple traffic profiles in a single signalling
message. This section can be removed in later versions of the draft
such that it reflects only the recommended approach below.
4.1 Possible Solutions for RSVP-TE
To extend per-OA or per-CT 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
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.
4.2 Possible Solutions for CR-LDP
To extend per-OA or per-CT 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.
4.3 Preferred Solution
For CR-LDP, the approach of defining a new optional ELSP TLV is the
Ganti, Seddigh, Nandy [Page 9]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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 or per-CT 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.)
5. Application Scenarios
In this section we consider how the solution proposed in this draft
satisfies the required scenarios defined in [DS-TE-REQ].
1. Scenario 1: Limiting Voice to a percentage of link traffic
In order to satisfy the condition of limiting voice to a certain
percentage of link bandwidth, the incoming voice traffic must be
mapped to a separate CT from the data traffic. There may be multiple
CTs for different types of data traffic. While it is possible for a
multiple-OA E-LSP to carry multiple data traffic CTs, such E-LSPs
must not carry voice traffic. The voice traffic must be carried on
Ganti, Seddigh, Nandy [Page 10]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
its own LSP. The voice CT LSPs can be assigned a lower pre-emption
priority than the aggregated data E-LSP. In this way, voice will be
restricted to the desired portion of link capacity and voice LSPs
will be able to pre-empt LSPs that are carrying data.
2. Scenario 2: Maintain Relative Proportion of Traffic Classes
In order to satisfy the condition of supporting three traffic classes
with distinct link proportion requirements, it is necessary to define
three CTs - one for each class. Bandwidth constraints can then be
applied against the CTs depending on which bandwidth model is used.
If the maximum allocation model is used, then each CT will have a
different bandwidth constraint and the sum total of the bandwidth
constraints should add up to 100%. Alternatively, the Russian Doll
model can also be used. If there is no requirement for different
pre-emption then multiple CT bandwidth requirements can be signalled
on a single E-LSP. Otherwise, if there is an additional requirement
that each class maps to a different pre-emption priority then an E-
LSP can carry only a single CT.
3. Scenario 3: Guaranteed Bandwidth Service
Scenario 3 can be satisfied using a mechanism similar to that
described in scenario 1 above.
6. 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 (or CTs) in an E-
LSP. The extensions specified in this section only relate to E-LSPs
and do not apply to L-LSPs.
6.1 ELSP Object Definition
Ganti, Seddigh, Nandy [Page 11]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
To signal traffic profiles for multiple OAs (or CTs) 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 or per-CT 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VF | Reserved | numTP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (numTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 26 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.
VF : 2 bits, Validity Flag.
Indicates how CT and PSC fields should be treated. This
flag is valid for and applies to all enclosed Traffic Profiles
VF = 00 not allowed
VF = 01 means PSC field is only valid
VF = 10 means CT field is only valid
VF = 11 means both CT and PSC fields are valid
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 12]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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 | CT | 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
CT : 3 bits,
Indicates the Class-Type. Values currently allowed are
1, 2, ..., 7.
The PSC is encoded as specified in [PHBID]. The purpose of VF is to
indicate how the CT and PSC fields should be treated. For example,
VF=01 is used for networks that do not support CT and only support
PSC and VF=10 is used for networks that do not support PSC and only
support CT. VF=11 is used for networks that support both PSC and CT.
In that case, the two fields can be used togther as a mapping between
the CT and PSC. Appropriate error condition must be generated when
wrong VF is indicated. The bit mapping of CT must follow the CT
mapping as defined in [DS-CT].
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.
6.2 Handling of ELSP Object
The ELSP object is optional with respect to RSVP.
To signal per-OA or per-CT traffic profiles on an ELSP, a sender MUST
include the ELSP object in the PATH message. If the PATH message
Ganti, Seddigh, Nandy [Page 13]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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
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 or per-CT resource reservation SHOULD
generate a PATH_ERR message with error value: "Unsupported object".
A node that receives a PATH message with an ELSP object having VF=01
and which supports per-CT resource reservation but does not support
per-OA resource reservation SHOULD generate a PATH_ERR message with
error value: "No support for PSC signaling".
A node that receives a PATH message with an ELSP object having VF=10
and which supports per-OA resource reservation but does not support
per-CT resource reservation SHOULD generate a PATH_ERR message with
error value: "No support for CT signaling".
If a PATH message contains an ELSP object and a node is able to
recognize and process the ELSP object, it should ignore the CT object
if it is signalled.
The ELSP object MUST not be signaled in L-LSPs. LSRs that see the
ELSP object in the signalling for an L-LSP should ignore this object.
If an LSR rejects a resource reservation for a particular OA (or CT)
signaled in an ELSP, it SHOULD consider the resource reservation to
Ganti, Seddigh, Nandy [Page 14]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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 or CT".
6.3 RSVP Error Values 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 or CT
2 Unsupported ELSP Object
3 Unsupported PSC for per-OA signaled E-LSP
4 Unsupported CT for the signaled E-LSP
5 No support for PSC Signaling
6 No support for CT Signaling
7.0 CR-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.
7.1 ELSP TLV
The ELSP TLV has the following format:
Ganti, Seddigh, Nandy [Page 15]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VF | Reserved | numTP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TP (numTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 26 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.
VF : 2 bits, Validity Flag.
Indicates how CT and PSC fields should be treated. This
flag is valid for and applies to all enclosed Traffic Profiles
VF = 00 not allowed
VF = 01 means PSC field is only valid
VF = 10 means CT field is only valid
VF = 11 means both CT and PSC fields are valid
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]):
Ganti, Seddigh, Nandy [Page 16]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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 | CT | 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CT : 3 bits,
Indicates the Class-Type. Values currently allowed are
1, 2, ..., 7.
The PSC is encoded as specified in [PHBID]. The purpose of VF is to
indicate how the CT and PSC fields should be treated. For example,
VF=01 is used for networks that do not support CT and only support
PSC and VF=10 is used for networks that do not support PSC and only
support CT. VF=11 is used for networks that support both PSC and CT.
In that case, the two fields can be used togther as a mapping between
the CT and PSC. Appropriate error condition must be generated when
wrong VF is indicated. The remaining parameters are as specified in
the traffic parameters TLV of CR-LDP [CR-LDP]. The bit mapping of CT
must follow the CT mapping as defined in [DS-CT].
7.2 LDP Messages
The Label Request, Label Mapping and Notification messages are
extended to optionally contain the ELSP TLV. In addition, new status
codes are defined in the status code field of the Status TLV.
7.3 Handling of the ELSP TLV
7.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
7.3.2 Handling of the ELSP TLV in Downstream on Demand Mode
Ganti, Seddigh, Nandy [Page 17]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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 sender SHOULD not include an ELSP TLV with 0 TP entries in the
Label Request message. Such an TLV SHOULD be ignored by intermediate
LSRs and the receiving LER.
A node that receives a Label Request message with an ELSP TLV but
which does not support per-OA or per-CT resource reservation should
generate a Notification message with Status TLV and Status Code of
'Unsupported object'.
A node that receives a Label Request message with ELSP TLV having
VF=01 and which supports per-CT resource reservation but does not
support per-OA resource reservation SHOULD generate a Notification
message with Status Code of 'No support for PSC signaling'.
A node that receives a Label Request message with ELSP TLV having
VF=10 and which supports per-OA resource reservation but does not
support per-CT resource reservation SHOULD generate a Notification
message with Status Code 'No support for CT signaling'.
If a Label Request message contains an ELSP object and a node is able
to recognize and process this TLV, it should ignore the CT TLV if it
is also included.
The ELSP TLV should not be signaled in L-LSPs. LSRs that see the ELSP
TLV in the signaling for an L-LSP should ignore this TLV.
Ganti, Seddigh, Nandy [Page 18]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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.
7.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
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.
7.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
Unsupported CT 0 0x01000013
No support for PSC Signaling 0 0x01000014
No support for CT Signaling 0 0x01000015
8.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.
9.0 Acknowledgements
This work has benefitted from mailing list and offline discussion
involving Jim Boyle, Shahram Davari, Neil Harrison and Roberto
Ganti, Seddigh, Nandy [Page 19]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
Mameli.
10.0 References
[BITAR] Bitar N et al, "Traffic Engineering Extensions to OSPF",
Internet Draft, <draft-bitar-rao-diffserv-mpls-01.txt>,
July 2001
[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] Francois et al, "MPLS Support of Differentiated Services"
draft-ietf-mpls-diff-ext-09.txt, April 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.
[DS-TE-REQ] Le Faucheur F et al, "Requirements for support of
Diff-Serv-aware MPLS Traffic Engineering",
draft-ietf-tewg-diff-te-reqts-04.txt, April 2002.
[DS-CT] Le Faucheur F et al, "Protocol Extensions for support of
Diffserv-Aware MPLS Traffic Engineering,
draft-ietf-tewg-diff-te-proto-00.txt, February 2002.
Ganti, Seddigh, Nandy [Page 20]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
11.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.
This section is historical in nature and used only to illustrate the
other possible ways in which RSVP signaling could be extended to
support signaling of multiple OAs. Accordingly, the extensions have
not been updated to reflect support for signaling of multiple CTs on
an LSP. It is expected that eventually, this section may be removed
from the draft.
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
Ganti, Seddigh, Nandy [Page 21]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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
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.
Ganti, Seddigh, Nandy [Page 22]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Ganti, Seddigh, Nandy [Page 23]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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)
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ganti, Seddigh, Nandy [Page 24]
INTERNET DRAFT draft-ganti-mpls-diffserv-elsp-02.txt December 2002
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 25]