draft-geib-tsvwg-diffserv-intercon-07.txt   draft-geib-tsvwg-diffserv-intercon-08.txt 
TSVWG R. Geib, Ed. TSVWG R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational D. Black Intended status: Informational D. Black
Expires: April 27, 2015 EMC Corporation Expires: May 16, 2015 EMC Corporation
October 24, 2014 November 12, 2014
DiffServ interconnection classes and practice DiffServ interconnection classes and practice
draft-geib-tsvwg-diffserv-intercon-07 draft-geib-tsvwg-diffserv-intercon-08
Abstract Abstract
This document proposes a limited and well defined set of DiffServ This document proposes a limited and well defined set of DiffServ
PHBs and codepoints to be applied at (inter)connections of two PHBs and codepoints to be applied at (inter)connections of two
separately administered and operated networks. Many network separately administered and operated networks. Many network
providers operate MPLS using Treatment Aggregates for traffic marked providers operate MPLS using Treatment Aggregates for traffic marked
with different DiffServ PHBs, and use MPLS for interconnection with with different DiffServ PHBs, and use MPLS for interconnection with
other networks. This document offers a simple interconnection other networks. This document offers a simple interconnection
approach that may simplify operation of DiffServ for network approach that may simplify operation of DiffServ for network
interconnection among providers. interconnection among providers.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2015. This Internet-Draft will expire on May 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Related work . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 4
2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . . 5 2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 5
3. An Interconnection class and codepoint scheme . . . . . . . . 6 3. An Interconnection class and codepoint scheme . . . . . . . . 6
3.1. End-to-end QoS: PHB and DS CodePoint Transparency . . . . 11 3.1. End-to-end QoS: PHB and DS CodePoint Transparency . . . . 11
3.2. Treatment of Network Control traffic at carrier 3.2. Treatment of Network Control traffic at carrier
interconnection interfaces . . . . . . . . . . . . . . . . 12 interconnection interfaces . . . . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Annex A Carrier interconnection related DiffServ
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 aspects . . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Annex 2 The MPLS Short Pipe Model and IP traffic . . 17
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
DiffServ has been deployed in many networks. As described by section DiffServ has been deployed in many networks. As described by section
2.3.4.2 of RFC 2475, remarking of packets at domain boundaries is a 2.3.4.2 of RFC 2475, remarking of packets at domain boundaries is a
DiffServ feature [RFC2475]. This draft proposes a set of standard DiffServ feature [RFC2475]. This draft proposes a set of standard
QoS classes and code points at interconnection points to which and QoS classes and code points at interconnection points to which and
from which locally used classes and code points should be mapped. from which locally used classes and code points should be mapped.
RFC2474 specifies the DiffServ Codepoint Field [RFC2474]. RFC2474 specifies the DiffServ Codepoint Field [RFC2474].
skipping to change at page 8, line 47 skipping to change at page 8, line 24
RFC 4594's Multimedia Streaming class has not been mapped to the RFC 4594's Multimedia Streaming class has not been mapped to the
above scheme. By the time of writing, the most popular streaming above scheme. By the time of writing, the most popular streaming
applications use TCP transport and adapt picture quality in the case applications use TCP transport and adapt picture quality in the case
of congestion. These applications are proprietary and still change of congestion. These applications are proprietary and still change
behaviour frequently. At this state, the Bulk Real-Time Treatment behaviour frequently. At this state, the Bulk Real-Time Treatment
Aggregate or the Bulk Real-Time Treatment Aggregate may be a Aggregate or the Bulk Real-Time Treatment Aggregate may be a
reasonable match. reasonable match.
The overall approach to DSCP marking at network interconnections is The overall approach to DSCP marking at network interconnections is
illustrated by the following example. Provider O and provider W are illustrated by the following example. Provider O and provider W are
peered with provider T. They have agreed upon a QoS interconnection peered with provider T. They have agreed upon a QoS interconnection
SLA. SLA.
Traffic of provider O terminates within provider Ts network, while Traffic of provider O terminates within provider Ts network, while
provider W's traffic transits through the network of provider T to provider W's traffic transits through the network of provider T to
provider F. Assume all providers to run their own internal codepoint provider F. Assume all providers to run their own internal codepoint
schemes for a PHB groupwith properties of the DiffServ Intercon schemes for a PHB groupwith properties of the DiffServ Intercon
Assured Treatment Aggregate. Assured Treatment Aggregate.
Provider-O Provider-W Provider-O Provider-W
RFC5127 GSMA 34.1 RFC5127 GSMA 34.1
| | | |
+----------+ +----------+ +----------+ +----------+
|AF21, AF22| | CS3, CS2 | |AF21, AF22| | CS3, CS2 |
+----------+ +----------+ +----------+ +----------+
| | | |
skipping to change at page 10, line 30 skipping to change at page 10, line 8
It is easily visible that all providers only need to deploy internal It is easily visible that all providers only need to deploy internal
DSCP to DiffServ Intercon DSCP mappings to exchange traffic in the DSCP to DiffServ Intercon DSCP mappings to exchange traffic in the
desired classes. Provider W has decided that the properties of his desired classes. Provider W has decided that the properties of his
internal classes CS3 and CS2 are best met by the Diffserv Intercon internal classes CS3 and CS2 are best met by the Diffserv Intercon
Assured Elastic Treatment Aggregate, PHBs AF31 and AF32 respectively. Assured Elastic Treatment Aggregate, PHBs AF31 and AF32 respectively.
At the outgoing peering interface connecting provider W with provider At the outgoing peering interface connecting provider W with provider
T remarks CS3 traffic to AF31 and CS 2 traffic to CS32. The domain T remarks CS3 traffic to AF31 and CS 2 traffic to CS32. The domain
internal PHBs of provider T meeting the Diffserv Intercon Assured internal PHBs of provider T meeting the Diffserv Intercon Assured
Elastic Treatment Aggregate requirements is AF2. Hence AF31 traffic Elastic Treatment Aggregate requirements is AF2. Hence AF31 traffic
received at the interconnection with provider T is remarked to AF21 received at the interconnection with provider T is remarked to AF21
by the peering router of domain T. As domain T deploys MPLS, further by the peering router of domain T. As domain T deploys MPLS, further
the MPLS TC ist set to 2. Traffic received with AF32 is remarked to the MPLS TC ist set to 2. Traffic received with AF32 is remarked to
AF22. The MPLS TC of the Treatment Aggregate is the same, TC 2. At AF22. The MPLS TC of the Treatment Aggregate is the same, TC 2. At
the pen-ultimate MPLS node, the top MPLS label is removed. The the pen-ultimate MPLS node, the top MPLS label is removed. The
packet should be forwarded as determined by the incoming MPLS TC. packet should be forwarded as determined by the incoming MPLS TC.
The peering router connecting domain T with domain F classifies the The peering router connecting domain T with domain F classifies the
packet by it's domain T internal DSCP AF21 for the Diffserv Intercon packet by it's domain T internal DSCP AF21 for the Diffserv Intercon
Assured Elastic Treatment Aggregate. As it leaves domain T on the Assured Elastic Treatment Aggregate. As it leaves domain T on the
interface to domain F, it is remarked to AF31. The peering router of interface to domain F, it is remarked to AF31. The peering router of
domain F classifies the packet for domain F internal PHB CS4, as this domain F classifies the packet for domain F internal PHB CS4, as this
is the PHB with properties matching DiffServ Intercon's Assured is the PHB with properties matching DiffServ Intercon's Assured
skipping to change at page 14, line 20 skipping to change at page 13, line 41
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474, December
December 1998. 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
skipping to change at page 15, line 11 skipping to change at page 14, line 34
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic", Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, May 2010. RFC 5865, May 2010.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006. [min_ref] authSurName, authInitials., "Minimal Reference", 2006.
7.2. Informative References 7.2. Informative References
[I-D.knoll-idr-cos-interconnect] [I-D.knoll-idr-cos-interconnect]
Knoll, T., "BGP Class of Service Interconnection", Knoll, T., "BGP Class of Service Interconnection", draft-
draft-knoll-idr-cos-interconnect-12 (work in progress), knoll-idr-cos-interconnect-13 (work in progress), November
May 2014. 2014.
[ID.idr-sla] [ID.idr-sla]
IETF, "Inter-domain SLA Exchange", IETF, http:// IETF, "Inter-domain SLA Exchange", IETF,
datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/, http://datatracker.ietf.org/doc/
2013. draft-ietf-idr-sla-exchange/, 2013.
[IEEE802.1Q] [IEEE802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Virtual Bridged Local Area Networks", 2005. Networks - Virtual Bridged Local Area Networks", 2005.
[IR.34] GSMA Association, "IR.34 Inter-Service Provider IP [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP
Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http:/ Backbone Guidelines Version 7.0", GSMA, GSMA IR.34
/www.gsma.com/newsroom/wp-content/uploads/2012/03/ http://www.gsma.com/newsroom/wp-content/uploads/2012/03/
ir.34.pdf, 2012. ir.34.pdf, 2012.
[MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet
Class of Service Phase 2", MEF, MEF23.1 http:// Class of Service Phase 2", MEF, MEF23.1
metroethernetforum.org/PDF_Documents/ http://metroethernetforum.org/PDF_Documents/technical-
technical-specifications/MEF_23.1.pdf, 2012. specifications/MEF_23.1.pdf, 2012.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
RFC 2983, October 2000. 2983, October 2000.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594, August
August 2006. 2006.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, February 2008. Diffserv Service Classes", RFC 5127, February 2008.
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-
to-Provider Agreements for Internet-Scale Quality of to-Provider Agreements for Internet-Scale Quality of
Service (QoS)", RFC 5160, March 2008. Service (QoS)", RFC 5160, March 2008.
[Y.1566] ITU-T, "Quality of service mapping and interconnection [Y.1566] ITU-T, "Quality of service mapping and interconnection
between Ethernet, IP and multiprotocol label switching between Ethernet, IP and multiprotocol label switching
networks", ITU, networks", ITU,
http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012.
Appendix A. Change log Appendix A. Annex A Carrier interconnection related DiffServ aspects
This annex provides a general discussion of PHB and DSCP mapping at
IP interconnection interfaces. It also informs about limitations and
likely DSCP changes.
The following scenarios start from a domain sending non-tunneled IP
traffic using a PHB and a corresponding DSCP to an interconnected
domain. The receiving domain may
o Support the PHB and offer the same corresponding DSCP.
o Not support the PHB and use the DSCP for a different PHB.
o Not support the PHB and not use the DSCP.
o Support the PHB with a differing DSCP, and the DSCP of the sending
domain is not used for another PHB
o Support the PHB with a differing DSCP, and the DSCP of the sending
domain is used for another PHB.
RFC2475 allows for local use PHB groups which are only available
within a domain. If such a local use PHB is present, non-tunneled IP
traffic possibly cannot utilize 64 DSCPs end-to-end.
If a domain receives traffic for a PHB, which it does not support,
there are two general scenarios:
o The received DSCP is not available for usage within the domain.
o The received DSCP is available for usage within the domain.
RFC2474 suggests to transport packets received with unrecognized
DSCPs by the default PHB and leave the DSCP as received. Also if a
particular DSCP is spare within a domain, it may later change its QoS
design and assign a PHB to a formerly unused DSCP (which a customer
used to transit through this unrecognized DSCP will note, as his DSCP
will the be remarked). A transparent transport of the same DSCP as
unknown with the default PHB may no longer be possible. Remarking to
another DSCP apart from the Default PHBs DSCP does not seem to be a
good option in the latter case. Which other DSCP is making sense?
If a domain interconnects with many other domains, the questions
asked here may have to be answered multiple times.
The scenarios above indicate, that reliably delivering a non-tunneled
IP packet by the same PHB and DSCP unchanged end-to-end is only
likely, if both domains support this DSCP and use the same
corresponding DSCP.
Limitations in the number of supported PHBs are to be expected if
DiffServ is applied across different domains. Unchanged end-to-end
DSCPs should only be expected for non-tunneled IP traffic, if the PHB
and DSCP are well specified and generally deployed. This is true for
Default Forwarding. EF PHB is a candidate. The Network Control PHB
is a local use only example, hence end-to-end support of CS6 for non-
tunneled IP traffic at interconnection points should only be
expected, if the receiving domain regards this traffic as Network
Control traffic relevant for the own domain too.
DiffServ Intercon proposes a well defined set of PHBs and
corresponding DSCPs at interconnection points. A PHB to DSCPs
correspondence is specified at least for interconnection interfaces.
Supported PHBs should be available end-to-end, but domain internal
DSCPs may change end-to-end.
Appendix B. Annex 2 The MPLS Short Pipe Model and IP traffic
The MPLS Short Pipe Model (or Pen-ultimate Hop Label Popping) is
widely deployed by IP carriers. If non-tunneled IPv4 traffic is
transported using MPLS Short Pipe, IP headers appear inside the last
section of the MPLS domain. This likely impacts the number of PHBs
and DSCPs a network provider supports for this kind of traffic.
Figure 2 provides an example for the treatment of this kind of
traffic.
In the case of tunneled IPv4 traffic, only the outer tunnel header is
exposed. Assuming the tunnel not to terminate within the MPLS
network section, only the outer tunnel DSCP is impacted.
Non-tunneled IPv6 traffic and Layer 2 and Layer 3 VPN traffic all use
an additional label. Hence no IP header is exposed within an MPLS
domain.
Carriers may first design their own QoS PHB and codepoint scheme
before they worry about interconnection. PHB and corresponding
codepoint schemes usually differ between different carriers. PHBs
may be mapped. A DSCP rewrite should be expected at an
interconnection interface at least for plain IP traffic.
RFC3270 suggests deployment of the Short Pipe Model only in the case
of VPNs. State of the art deployments also support transport of non
tunneled IPv4 traffic. This is shown in figure 2.
|
\|/ IPv4, DSCP_send
V
|
Peering Router
|
\|/ IPv4, DSCP_send
V
|
MPLS Edge Router
| Mark MPLS Label, TC_internal
\|/ Remark DSCP to
V (Inner: IPv4, DSCP_d)
|
MPLS Core Router (pen-ultimate hop label popping)
| \
| IPv4, DSCP_d | The DSCP needs to be in domain
| ^^^^^^^^| internal QoS context. The Core
\|/ > Router might require or enforce
V | it. The Edge Router may wrongly
| | classify, if the DSCP is not in
| / domain internal DiffServ context.
MPLS Edge Router
| \ With well defined PHBs and
\|/ IPv4, DSCP_d | corresponding DSCPs at interdomain
V > links, more than one DSCP per
| | treatment aggregate may pass a
| / domain and carry a well defined
Peer Router DSCP when leaving it.
| Remark DSCP to
\|/ IPv4, DSCP_send
V
|
Short-Pipe / Pen-ultimate hop popping example
Figure 2
The packets IP DSCP must be in a well understood Diffserv context for
schedulers and classifiers on the interfaces of the ultimate MPLS
link. These are domain internal and a domain operating in this mode
enforces DSCPs resulting in reliable domain internal QoS operation.
Without DiffServ-Intercon treatment, the traffic always leaves the
domain having internal DS codepoints. DSCP_send of the figure above
is remarked to the receiving domains DiffServ scheme. It leaves the
domain marked by the domains DSCP_d. Every carrier must deploy per
peer PHB and DSCP mapping schemes.
If DiffServ-Intercon is applied, only traffic terminating within a
domain must be aligned with the domain internal DiffServ Codepoint
scheme. Traffic transiting through the domain can be easily mapped
and remapped to an original DSCP. This is shown in figure 3. Of
course the domain internal limitations caused by the Short Pipe model
still apply.
Internal Router
|
| Outer Header
\|/ IPv4, DSCP_send
V
|
Peering Router
| Remark DSCP to
\|/ IPv4, DSCP_ds-int DiffServ Intercon DSCP and PHB
V
|
MPLS Edge Router
|
| Mark MPLS Label, TC_internal
\|/ Remark DSCP to
V (Inner: IPv4, DSCP_d) domain internal DSCP for
| the PHB
MPLS Core Router (pen-ultimate hop label popping)
|
| IPv4, DSCP_d
| ^^^^^^
\|/
V
|
|
MPLS Edge Router--------------------+
| |
\|/ Remark DSCP to \|/ IPv4, DSCP_d
V IPv4, DSCP_ds-int V
| |
| |
Peer Router Domain internal Broadband
| Access Router
\|/ Remark DSCP to \|/
V IPv4, DSCP_send V IPv4, DSCP_d
| |
Short-Pipe example with Diffserv-Intercon
Figure 3
Picking up terminology of RFC2983 and RFC3270, DiffServ intercon
emulates the long pipe model for the PHBs it supports, if traffic is
terminating in the receiving domain.
Looking at the peering interfaces only, for transiting QoS traffic
DiffServ-Intercon emulates the uniform model for the PHBs and DSCPs
supported. Packets are expected to leave a domain with the DSCP/PHB
as received (and per flow within each PHB in the same order as
received). MPLS Treatment Aggregates should not experience
congestion under standard operational conditions. The peering links
need to engineered to be congestion free too for QoS PHBs, if also
the IP transit transport is to be congestion free.
Appendix C. Change log
00 to 01 Added terminology and references. Added details and 00 to 01 Added terminology and references. Added details and
information to interconnection class and codepoint scheme. information to interconnection class and codepoint scheme.
Editorial changes. Editorial changes.
01 to 02 Added some references regarding related work. Clarified 01 to 02 Added some references regarding related work. Clarified
class definitions. Further editorial improvements. class definitions. Further editorial improvements.
02 to 03 Consistent terminology. Discussion of Network Management 02 to 03 Consistent terminology. Discussion of Network Management
PHB at interconnection interfaces. Editorial review. PHB at interconnection interfaces. Editorial review.
skipping to change at page 16, line 28 skipping to change at page 21, line 34
Control PHB at interconnection interfaces. Control PHB at interconnection interfaces.
04 to 05 Large rewrite and re-ordering of contents. 04 to 05 Large rewrite and re-ordering of contents.
05 to 06 Description of IP and MPLS related requirements and 05 to 06 Description of IP and MPLS related requirements and
constraints on DSCP rewrites. constraints on DSCP rewrites.
06 to 07 Largely rewrite, improved match and comparison with RFCs 06 to 07 Largely rewrite, improved match and comparison with RFCs
4594 and 5127. 4594 and 5127.
07 to 08 Added Annex A and B which where forgotten when putting
together -07
Authors' Addresses Authors' Addresses
Ruediger Geib (editor) Ruediger Geib (editor)
Deutsche Telekom Deutsche Telekom
Heinrich Hertz Str. 3-7 Heinrich Hertz Str. 3-7
Darmstadt, 64295 Darmstadt 64295
Germany Germany
Phone: +49 6151 5812747 Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de Email: Ruediger.Geib@telekom.de
David L. Black David L. Black
EMC Corporation EMC Corporation
176 South Street 176 South Street
Hopkinton, MA Hopkinton, MA
USA USA
Phone: +1 (508) 293-7953 Phone: +1 (508) 293-7953
Email: david.black@emc.com Email: david.black@emc.com
 End of changes. 21 change blocks. 
43 lines changed or deleted 252 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/