Network Working Group Jerry Ash
Internet Draft Chuck Dvorak
<draft-ash-mpls-diffserv-te-class-types-00.txt> Wai Sum Lai
Expiration Date: December 2002 Al Morton
Percy Tarapore
AT&T
June, 2002
Proposed MPLS/DiffServ TE Class Types
<draft-ash-mpls-diffserv-te-class-types-01.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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
ABSTRACT:
Service Provider requirements for support of DiffServ aware MPLS Traffic
Engineering (MPLS-DS-TE) are presented in [MPLS-DS-TE-REQ]. This initiative
includes the definition of MPLS-DiffServ-TE class types (CTs), wherein CTs
are defined as aggregations of individual service classes. Instead of
having per-class parameters being configured and propagated on each LSR
interface, classes are aggregated into CTs having common per-CT parameters
(e.g., minimum bandwidth) to satisfy required performance levels, however,
no bandwidth requirements are enforced for classes within a CT. The main
motivation for grouping a set of classes into a CT is to improve the
scalability of IGP LSAs by propagating information on a per-CT basis instead
of on a per-class basis, and also to allow better bandwidth sharing between
classes in the same CT. In order to further improve scalability through the
introduction of CTs, we propose to a) limit the number of CTs to 6, and b)
to generalize the notion of CTs and consider them to be a combination of i)
DiffServ/queuing priority per-hop-behaviors (PHBs), ii) QoS classes (e.g.,
as specified in [Y.1541]), iii) admission-control priority classes, and iv)
restoration priority classes at both the MPLS-LSP and transport link level.
Table of Contents
1. Introduction
2. Description of Proposed Class Types
3. Discussion of Proposed Class Type Definitions (Table 1)
4. Conveying Class-Type Designation in MPLS Signaling
5. Security Considerations
6. Acknowledgments
7. References
8. Authors' Addresses
9. Full Copyright Statement
1. Introduction
Service Provider requirements for support of DiffServ aware MPLS Traffic
Engineering (MPLS-DS-TE) are presented in [MPLS-DS-TE-REQ]. DS-TE is
discussed in the Traffic Engineering Working Group Framework document
[TEWG-FW]. DS-TE requirements are defined for class types (CTs), where CTs
are defined in [TEWG-FW] as aggregations of individual service classes.
Instead of having per-class parameters being configured and propagated on
each LSR interface, classes are aggregated into CTs having common per-CT
parameters (e.g., minimum bandwidth) to satisfy required performance levels,
however, no bandwidth requirements are enforced for classes within a CT. The
main motivation for grouping a set of classes into a CT is to improve the
scalability of IGP LSAs by propagating information on a per-CT basis instead
of on a per-class basis, and also to allow better bandwidth sharing between
classes in the same CT.
A CT is a set of classes that satisfy the following two conditions:
1) Classes in the same CT have common aggregate maximum bandwidth
requirements (and, if applicable, common minimum bandwidth requirements) to
satisfy required performance levels.
2) There is no maximum or minimum bandwidth requirement to be enforced at
the level of individual class in the CT.
An example of the CT can be a low-loss CT that includes both AF1-based and
AF2-based Ordering Aggregates. [DS-TE-SOLN] describes a proposed technical
solution for meeting the DS-TE requirements. The draft proposes complex IGP
extensions of per-CT link-state advertisements (LSA) to communicate per-CT
available bandwidth, etc. It already gets so complex that the draft
proposes to compress the advertisements. There is concern about scalability
of the IGP overhead, and particularly the IGP response to overloads and
failures [IGP-SCALE]. Hence there is concern about further significant
extensions to increase IGP overhead, which will further exacerbate the
problem identified in [IGP-SCALE]. Furthermore we think the extensions are
unnecessary, because there are other, equally effective ways to do DS-TE
without the IGP TE extensions, as described in [IGP-ALTERNATIVE].
In order to achieve further scalability through the introduction of CTs, we
propose to a) limit the number of CTs to 6, and b) to generalize the notion
of CTs and consider them to be a combination of i) DiffServ/queuing priority
per-hop behaviors (PHBs), ii) QoS classes (e.g., as specified in [Y.1541]),
iii) admission-control priority classes, and iv) restoration priority
classes at both the MPLS-LSP and transport link level. Admission control
priority is a way of giving preference to admit higher priority LSPs ahead
of lower priority LSPs. A high-priority service LSP can be admitted in
preference over a normal-priority service LSP. Restoration priority is a
way of giving preference to protect higher priority LSPs ahead of lower
priority LSPs. A high-priority service LSP can be protected in preference
over a normal-priority service LSP. For both admission control and
restoration, no preemption of existing LSPs is assumed beyond what is
specified for the proposed CT for control traffic, as described in the next
Section.
2. Description of Proposed Class-Types
We suggest that it might be useful to generalize CTs and consider them to be
a combination of
1. DiffServ/queuing priority PHBs,
2. QoS classes (e.g., as specified in Draft Recommendation Y.1541),
3. MPLS/CAC priority classes,
4. restoration priority classes at both the MPLS-LSP and transport link
level, and
5. preemption priority classes.
The above categories are inclusive of the CT definition given in [TEWG-FW],
but go beyond to include considerations of restoration priority. Within
this more general context, we propose definitions of 5 user-traffic CTs and
1 control-traffic CT, as summarized in Table 1. Note that the proposed CTs
are mapped to DiffServ PHBs, as well as to the corresponding QoS classes
specified in the current Draft Recommendation Y.1541. CAC priority and
restoration priority are also defined. The rationale for these designations
is discussed in the next Section.
Table 1. Proposed Class-Type Definitions
Class-Type | User-Traffic Control-Traffic
Characteristics | Class Type Class Type
----------------|--------------------------------------------------------
| 1 2 3 4 5 1
----------------|--------------------------------------------------------
DiffServ PHB; | EF; EF; AFxy; AFxy; BE; AFxy
| Inter- Inter Non- Non- Non-
| active; active; inter- inter- inter-
| Real- Real- active; active; active;
| time; time; Low- Low- Low-
| loss; loss; loss;
Y.1541 QoS | 0,1 0,1 2,3,4 2,3,4 5 2
Class; |
----------------|--------------------------------------------------------
Priority: | High Normal High Normal Best- High;
MPLS CAC; | Effort LSP
MPLS-restoration| Preemption
(per-LSP); | allowed
Transport |
restoration |
(per-transport- |
link) |
----------------|------------------------------------------------------
3. Discussion of Proposed Class-Type Definitions (Table 1)
Draft Recommendation [Y.1541] describes QoS classes and IP performance
objectives that support a wide range of user applications. The classes
group objectives for one-way IP packet delay, IP packet delay variation, IP
packet loss ratio, etc. Classes 0 and 1, which generally correspond to the
DiffServ EF PHB, support interactive real-time applications by specifying
mean delay of 100ms and 400ms, respectively, delay variation less than 50ms,
and loss ratio less than 10^-3. Classes 2, 3, and 4, which generally
correspond to the DiffServ AFxy PHB Group, support non-interactive
applications by specifying mean delay of 100ms, 400ms, and 1s, respectively,
unspecified delay variation, and loss ratio less than 10^-3. Class 5, which
generally corresponds to the DiffServ best-effort PHB, has all these
parameters unspecified. See [Y.1541] for more detail.
Admission control priority is a way of giving preference to admit higher
priority LSPs ahead of lower priority LSPs. In Table 1 we define high,
normal, and BE admission control priorities. A high-priority service LSP
can be admitted in preference over a normal-priority service LSP by
reserving the last-available, minimum-level of bandwidth (called the
"reserved bandwidth") for high-priority service LSP admissions vs.
normal-priority service LSP admissions. That is, the higher priority LSP
gets the reserved bandwidth when that is all the bandwidth left. This
concept is widely used in practice today for voice and data services (e.g.,
"800 gold service", "emergency communication service",
key-switched-digital-service, etc.). These are examples of real-world
services that we offer now and that we may want to carry forward in the
future to an MPLS-DS-TE architecture. There have also been several other
drafts posted on priority needs for emergency communication services [FOLTS,
SCHULZRINNE, BROWN].
In Table 1, we define restoration priority as either high, normal, or
best-effort. Note that restoration priority is a requirement from the
output of the traffic engineering working group (TEWG) design team's output
[TEWG-REQ]. Restoration priority is achieved by provisioning sufficient
backup capacity, as necessary, and allowing relative priority for access to
available bandwidth when there is contention for restoration bandwidth. For
example, a high restoration priority LSP can take precedence over a normal
priority LSP in accessing bandwidth, if there is contention. LSP preemption
might also be used, such as for high restoration priority, in which active
best-effort priority LSPs could be bumped to provide available bandwidth for
LSP restoration of high priority LSPs. It is useful to minimize preemption
so as not to interrupt established service.
As optical networks evolve, service providers will have the capability to
offer transport links with various restoration classes of service
[OIF2001.514]. For example, a service provider may chose to offer three
types of transport links with unique transport restoration characteristics:
high-priority (e.g., < 1 second restoration), normal-priority (e.g., < 10
seconds restoration), and unprotected (no restoration). From the perspective
of packet layers, different traffic classes (and their prospective customer
SLAs) will require to be fitted into one of these three types of restoration
classes. Hence, the high-priority traffic class may require routing
exclusively over links which have the highest restoration class of service
(e.g., restoration within 200 milliseconds). Conversely, the low
(unprotected) priority traffic class may not require any transport
restoration at all. Hence there is a need for selecting an LSP based on the
designated restoration priorities of the transport links.
A class type can contain the traffic of a subset of a DiffServ behavior
aggregate (BA) [DIFF-NEW], an example being the EF BA. The class-type
definition therefore relates the interactions of two levels: packet level
and LSP level. Packet level behaviors are governed by DiffServ forwarding
treatment, which is responsible for packet-level QoS such as delay/jitter,
while LSP level is for link bandwidth allocation, which is responsible for
LSP level QoS such as ensuring that bandwidth requests can be met.
For the EF-high priority CT 1 and EF-normal priority CT 2, the 'high'
priority and 'normal' priority refer to admission/CAC priority for gaining
access to bandwidth, and not packet-level priority. Packet-level priority
is to differentiate between EF, AF, and BE. At the packet level, there is
only 1 EF queue that is being used by both EF-high and EF-normal priority
LSPs. MPLS-DS-TE is used to allocate and manage bandwidth at the LSP level
and this is why we can distinguish between EF-high and EF-normal for
bandwidth access. Once bandwidth access is gained and the respective LSP is
set up, there is no distinction any more in terms of packet-level QoS and
hence there is only 1 EF queue.
The point of doing this is so that we can have separate bandwidth pools for
CT 1 (EF-high) and CT 2 (EF-normal). Furthermore, depending on
implementation, in some specific links, we may want to limit the combined
bandwidth pool available to both EF CTs to some maximum bandwidth. However,
such actions can be done purely internal to a router. Hence, no
advertisement of the combined limitation on bandwidth information needs to
be propagated.
The inclusion of DiffServ PHBs, QoS classes, admission-control priority
classes, restoration priority, and preemption priority classes into a
combined set of 6 CT definitions is intended to minimize the number of
possible CTs across these 4 levels of priority classes. That is, if the
number of DiffServ/QoS PHBs = W
number of admission-control priority levels = X
number of restoration priority levels = Y
number of preemption priority levels = Z
Then the combination of the possible number of CTs when considering all 4
dimensions independently would be
number of independent CTs = WXYZ
This number of independent CTs could therefore be a very large number.
Hence in Table 1 we propose 6 CTs, which combine the 4 dimensions into a
smaller number (6) of combinations. We feel that this approach is more
scalable than allowing a very large number of CT combinations.
A separate CT is defined for network control traffic [LAI]. This is for
control traffic generated by routing protocols, network management, and
signaling to support service requests. This class of traffic has the
following characteristics:
1. must have a very low drop precedence: e.g., dropped control traffic
may cause routing to fail or flap, leading to network instability or even
prolonged and widespread network failure,
2. a relatively small bandwidth guarantee under normal network
conditions: to minimize overhead (control traffic is usually designed to
consume a relatively small amount of bandwidth),
3. high priority: large user packets on slow links may cause
significant delays that will reduce the responsiveness needed by control
traffic,
4. preemption of all other traffic under overload or failed conditions:
to ensure that control traffic gets through with minimal loss and delay.
4. Conveying Class-Type Designation in MPLS Signaling
A particular CT designation would be associated with each MPLS LSP.
As such, each of the parameters proposed in Table 1 would need to be
signaled to define the CT. DiffServ/QoS PHB, CAC priority, and preemption
priority information can be conveyed in LSP setup using existing MPLS
DiffServ extensions [DIFF-MPLS] and Priority TLVs already being specified
[RSVP-TE, CR-LDP]. Conveying the restoration priority information could be
done in the Restoration TLV being defined.
Through the use of constraint-based LSP routing, color or "resource
class" [TSVP-TE, CR-LDP] is an MPLS mechanism that could be used to route
packets with a given priority on links/facilities with a given restoration
priority. The use of color or resource classes for transport level
restoration is illustrated with the following simple example. Consider a
small network of four LSRs: A, B, C, and D. Assume that the bulk of the
class-type traffic fits into the normal-priority transport restoration class
and the remainder requires the high-priority transport restoration class.
Accordingly, with the use of traffic engineering, four OC-48 links marked
normal-priority are implemented with one OC-48 linking LSRs A and B, one
OC-48 linking LSRs B and C, one OC-48 linking LSRs C and D, and one OC-48
linking LSRs D and A. Further, six OC-3 links marked high-priority are
implemented in a fully meshed design: one OC-3 between each of the LSR pairs
A and B, B and C, C and D, D and A, A and C, B and D. For class types
requiring a high-priority path between LSR A and C, the LSP setup would be
over the high-priority-OC-3 between LSR A and C. For class types requiring a
normal-priority path between LSRs A and C, the LSP setup would be over the
normal-priority-OC-48 between LSRs A and B followed by the
normal-priority-OC-48 between LSRs B and C.
5. Security Considerations
There are no new security considerations based on proposals in this draft.
6. Acknowledgements
We appreciate comments and suggestions from Kwangil Lee of NIST and Tricci
So of Caspian Networks.
7. References
[BROWN] Brown, I., et. al., "Securing prioritised emergency traffic," work
in progress.
[CR-LDP] Jamoussi, B., et. al., RFC 3212, "Constraint-Based LSP Setup using
LDP".
[DIFF-MPLS] Le Faucheur, F., et. al., RFC 3270, "MPLS Support of Diff-Serv".
[DIFF-NEW] Grossman, D., "New Terminology for Diffserv", work in progress.
[FOLTS] Folts, H., "Emergency Telecommunications Service in Next-Generation
Networks ," work in progress.
[IGP-SCALE] Ash, G., et. al., "Proposed Mechanisms for Congestion
Control/Failure Recovery in OSPF & ISIS Networks," work in progress.
[IGP-ALTERNATIVE] Ash, G., et. al., "Alternative Technical Solution for MPLS
DiffServ TE," work in progress.
[ISIS-TE] Li, T., et. al., "IS-IS extensions for Traffic Engineering," work
in progress.
[MPLS-ARCHITECTURE] Rosen, E., et. al., RFC 3031, "Multiprotocol Label
Switching Architecture".
[MPLS-DS-TE-REQ] Le Faucheur, F., et. al., "Requirements for support of
Diff-Serv-aware MPLS Traffic Engineering," work in progress.
[OSPF-TE] Katz, D., et. al., "Traffic Engineering Extensions to OSPF," work
in progress.
[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", work in progress.
[SCHULZRINNE] Schulzrinne, H., "Emergency Call Services for SIP-based
Internet Telephony," work in progress.
[TE-REQ] Awduche, D., et. al., "Requirements for Traffic Engineering over
MPLS," RFC2702, September 1999.
[TEWG-FW] Awduche, D., et. al., RFC 3272, "Overview and Principles of
Internet Traffic Engineering."
[TEWG-REQ] Lai, W. S., et. al., "Network Hierarchy and Multilayer
Survivability," work in progress.
[LAI] Lai, W. S., "Traffic Measurement for Dimensioning and Control of IP
Networks," Internet Performance and Control of Network Systems II
Conference, SPIE Proceedings Vol. 4523, Denver Colorado, 21-22 August 2001.
[Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives
for IP-Based Services.
8. Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Fax: +1-(732)-368-8659
Email: gash@att.com
Chuck Dvorak
AT&T
Room 2A37
180 Park Avenue, Building 2
Florham Park, NJ 07932
Phone: + 1 973-236-6700
Fax:+1 973-236-7453
E-mail: cdvorak@att.com
Wai Sum Lai
AT&T
Room D5-3D18
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: +1 732 420-3712
Fax:+1 732 368-1919
E-mail: wlai@att.com
Al Morton
AT&T
Room D3-3C06
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-1571
Fax: +.1 732 368-1192
E-mail: acmorton@att.com
Percy Tarapore
AT&T
Room D1-3D33
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-4172
E-mail: tarapore@.att.com
9. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist in
its implementation may be prepared, copied, published and distributed, in
whole or in part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such copies and
derivative works.
However, this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined in
the Internet Standards process must be followed, or as required to translate
it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.