draft-ietf-diffserv-pdb-def-02.txt   draft-ietf-diffserv-pdb-def-03.txt 
Internet Engineering Task Force K. Nichols Internet Engineering Task Force K. Nichols
Differentiated Services Working Group Packet Design Differentiated Services Working Group Packet Design
Internet Draft B. Carpenter Internet Draft B. Carpenter
Expires in June, 2001 IBM Expires in July, 2001 IBM
Definition of Differentiated Services Per Domain Behaviors Definition of Differentiated Services Per Domain Behaviors
and Rules for their Specification and Rules for their Specification
<draft-ietf-diffserv-pdb-def-02> <draft-ietf-diffserv-pdb-def-03>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at line 77 skipping to change at line 77
This document defines and discusses Per-Domain Behaviors in detail This document defines and discusses Per-Domain Behaviors in detail
and lays out the format and required content for contributions and lays out the format and required content for contributions
to the Diffserv WG on PDBs and the procedure that will be applied to the Diffserv WG on PDBs and the procedure that will be applied
for individual PDB specifications to advance as WG products. This for individual PDB specifications to advance as WG products. This
format is specified to expedite working group review of PDB submissions. format is specified to expedite working group review of PDB submissions.
A pdf version of this document is available at: A pdf version of this document is available at:
www.packetdesign.com/ietf/diffserv/pdb_def.pdf. www.packetdesign.com/ietf/diffserv/pdb_def.pdf.
Contents
1. Introduction ................................................2
2. Definitions .................................................3
3. The Value of Defining Edge-to-Edge Behavior .................4
4. Understanding PDBs ..........................................5
5. Format for Specification of Diffserv Per-Domain Behaviors ..10
6. On PDB Attributes ..........................................11
7. A Reference Per-Domain Behavior ............................13
8. Guidelines for Advancing PDB Specifications ................15
9. Security Considerations ....................................15
10. Acknowledgements ...........................................15
1 Introduction 1 Introduction
Differentiated Services allows an approach to IP Quality of Service Differentiated Services allows an approach to IP Quality of Service
that is modular, incrementally deployable, and scalable while that is modular, incrementally deployable, and scalable while
introducing minimal per-node complexity [RFC2475]. From the end user's introducing minimal per-node complexity [RFC2475]. From the end user's
point of view, QoS should be supported end-to-end between any pair of point of view, QoS should be supported end-to-end between any pair of
hosts. However, this goal is not immediately attainable. It will hosts. However, this goal is not immediately attainable. It will
require interdomain QoS support, and many untaken steps remain require interdomain QoS support, and many untaken steps remain
on the road to achieving this. One essential step, the evolution on the road to achieving this. One essential step, the evolution
of the business models for interdomain QoS, will necessarily develop of the business models for interdomain QoS, will necessarily develop
skipping to change at line 253 skipping to change at line 265
domains or Autonomous Systems (ASs), represented by the "clouds" domains or Autonomous Systems (ASs), represented by the "clouds"
in figure 1. To deploy ubiquitous end-to-end quality of service in figure 1. To deploy ubiquitous end-to-end quality of service
in the Internet, business models must evolve that include issues in the Internet, business models must evolve that include issues
of charging and reporting that are not in scope for the IETF. In of charging and reporting that are not in scope for the IETF. In
the meantime, there are many possible uses of quality of service the meantime, there are many possible uses of quality of service
within an AS and the IETF can address the technical issues in creating within an AS and the IETF can address the technical issues in creating
an intradomain QoS within a Differentiated Services framework. an intradomain QoS within a Differentiated Services framework.
In fact, this approach is quite amenable to incremental deployment In fact, this approach is quite amenable to incremental deployment
strategies. strategies.
Where DS domains are independently administered, the evolution of
the necessary business agreements and future signaling arrangements
will take some time, thus, early deployments will be within a single
administrative domain. Putting aside the business issues, the same
technical issues that arise in interconnecting DS domains with
homogeneous administration will arise in interconnecting the autonomous
systems (ASs) of the Internet.
---------------------------------------- ----------------------------------------
| AS2 | | AS2 |
| | | |
------- | ------------ ------------ | ------- | ------------ ------------ |
| AS1 |------|-----X | | | | | AS1 |------|-----X | | | |
------- | | | Y | | ------- ------- | | | Y | | -------
| | | /| X----|--------| AS3 | | | | /| X----|--------| AS3 |
| | | / | | | ------- | | | / | | | -------
| | | / ------------ | | | | / ------------ |
| | Y | | | | Y | |
skipping to change at line 275 skipping to change at line 295
| AS4 |------|-----X | \| | | | AS4 |------|-----X | \| | |
------- | | | Y X----|------ ------- | | | Y X----|------
| | | | | | | | | | | |
| ------------ ------------ | | ------------ ------------ |
| | | |
| | | |
---------------------------------------- ----------------------------------------
Figure 1: Interconnection of ASs and DS Domains Figure 1: Interconnection of ASs and DS Domains
Where DS domains are independently administered, the evolution of
the necessary business agreements and future signaling arrangements
will take some time, thus, early deployments will be within a single
administrative domain. Putting aside the business issues, the same
technical issues that arise in interconnecting DS domains with
homogeneous administration will arise in interconnecting the autonomous
systems (ASs) of the Internet.
A single AS (e.g., AS2 in figure 1) may be composed of subnetworks A single AS (e.g., AS2 in figure 1) may be composed of subnetworks
and, as the definition allows, these can be separate DS domains. and, as the definition allows, these can be separate DS domains.
An AS might have multiple DS domains for a number of reasons, most An AS might have multiple DS domains for a number of reasons, most
notable being to follow topological and/or technological boundaries notable being to follow topological and/or technological boundaries
and to separate the allocation of resources. If we confine ourselves and to separate the allocation of resources. If we confine ourselves
to the DS boundaries between these "interior" DS domains, we avoid to the DS boundaries between these "interior" DS domains, we avoid
the non-technical problems of setting up a service and can address the non-technical problems of setting up a service and can address
the issues of creating characterizable PDBs. the issues of creating characterizable PDBs.
The incentive structure for differentiated services is based on The incentive structure for differentiated services is based on
skipping to change at line 712 skipping to change at line 724
Note that it is not necessary for a provider to expose which PDB Note that it is not necessary for a provider to expose which PDB
(if a commonly defined one) is being used nor is it necessary for (if a commonly defined one) is being used nor is it necessary for
a provider to specify a service by the PDB's attributes. For example, a provider to specify a service by the PDB's attributes. For example,
a service provider might use a PDB with a "no queueing loss" a service provider might use a PDB with a "no queueing loss"
characteristic in order to specify a "very low loss" service. characteristic in order to specify a "very low loss" service.
This section is to inject realism into the characteristics described This section is to inject realism into the characteristics described
above. Detail the assumptions made there and what constraints that above. Detail the assumptions made there and what constraints that
puts on topology or type of physical media or allocation. puts on topology or type of physical media or allocation.
5.8 Security Considerations for each PDB
This section should include any security considerations that are
specific to the PDB. Is it subject to any unusual theft-of-service
or denial-of-service attacks? Are any unusual security precautions
needed?
It is not necessary to repeat the general security discussions in
[RFC2474] and [RFC2475], but a reference should be included. Also
refer to any special security considerations for the PHB or PHBs
used.
6 On PDB Attributes 6 On PDB Attributes
As discussed in section 4, measurable, quantifiable attributes As discussed in section 4, measurable, quantifiable attributes
associated with each PDB can be used to describe what will happen to associated with each PDB can be used to describe what will happen to
packets using that PDB as they cross the domain. In its role as a build- packets using that PDB as they cross the domain. In its role as a build-
ing block for the construction of interdomain quality-of-service, a ing block for the construction of interdomain quality-of-service, a
PDB specification should provide the answer to the question: Under PDB specification should provide the answer to the question: Under
what conditions can we join the output of this domain to another what conditions can we join the output of this domain to another
under the same traffic conditioning and expectations? Although under the same traffic conditioning and expectations? Although
there are many ways in which traffic might be distributed, creating there are many ways in which traffic might be distributed, creating
skipping to change at line 864 skipping to change at line 888
the Internet. There is a potential for much interesting research the Internet. There is a potential for much interesting research
work. However, in submitting a PDB specification to the Diffserv work. However, in submitting a PDB specification to the Diffserv
WG, a PDB must also meet the test of being useful and relevant WG, a PDB must also meet the test of being useful and relevant
by a deployment experience, described in section 8. by a deployment experience, described in section 8.
7 A Reference Per-Domain Behavior 7 A Reference Per-Domain Behavior
The intent of this section is to define as a reference a Best Effort The intent of this section is to define as a reference a Best Effort
PDB, a PDB that has little in the way of rules or expectations. PDB, a PDB that has little in the way of rules or expectations.
7.1 Best Effort Behavior PDB 7.1 Best Effort PDB
7.1.1 Applicability 7.1.1 Applicability
A Best Effort (BE) PDB is for sending "normal internet traffic" A Best Effort (BE) PDB is for sending "normal internet traffic"
across a diffserv network. That is, the definition and use of this across a diffserv network. That is, the definition and use of this
PDB is to preserve, to a reasonable extent, the pre-diffserv delivery PDB is to preserve, to a reasonable extent, the pre-diffserv delivery
expectation for packets in a diffserv network that do not require expectation for packets in a diffserv network that do not require
any special differentiation. Although the PDB itself does not include any special differentiation. Although the PDB itself does not include
bounds on availability, latency, and packet loss, this does not bounds on availability, latency, and packet loss, this does not
preclude Service Providers from engineering their networks so as preclude Service Providers from engineering their networks so as
skipping to change at line 925 skipping to change at line 949
any ingress to any egress. any ingress to any egress.
7.1.6 Example uses 7.1.6 Example uses
1. For the normal Internet traffic connection of an organization. 1. For the normal Internet traffic connection of an organization.
2. For the "non-critical" Internet traffic of an organization. 2. For the "non-critical" Internet traffic of an organization.
3. For standard domestic consumer connections 3. For standard domestic consumer connections
7.1.7 Environmental Concerns
There are no environmental concerns specific to this PDB.
7.1.8 Securty Considerations for BE PDB
There are no specific security exposures for this PDB. See the
general security considerations in [RFC2474] and [RFC2475].
8 Guidelines for writing PDB specifications 8 Guidelines for writing PDB specifications
G1. Following the format given in this document, write a draft and G1. Following the format given in this document, write a draft and
submit it as an Internet Draft. The document should have "diffserv" submit it as an Internet Draft. The document should have "diffserv"
as some part of the name. Either as an appendix to the draft, or as some part of the name. Either as an appendix to the draft, or
in a separate document, provide details of deployment experience in a separate document, provide details of deployment experience
with measured results on a network of non-trivial size carrying with measured results on a network of non-trivial size carrying
realistic traffic and/or convincing simulation results (simulation realistic traffic and/or convincing simulation results (simulation
of a range of modern traffic patterns and network topologies as of a range of modern traffic patterns and network topologies as
applicable). The document should be brought to the attention of applicable). The document should be brought to the attention of
skipping to change at line 982 skipping to change at line 1015
If no active Diffserv Working Group exists: If no active Diffserv Working Group exists:
G3. Following discussion on relevant mailing lists, the authors G3. Following discussion on relevant mailing lists, the authors
should revise the Internet Draft and contact the IESG for "Expert should revise the Internet Draft and contact the IESG for "Expert
Review" as defined in section 2 of RFC 2434 [RFC2434]. Review" as defined in section 2 of RFC 2434 [RFC2434].
G4. Subsequent to the review, the IESG may recommend publication G4. Subsequent to the review, the IESG may recommend publication
of the Draft as an RFC, request revisions, or decline to publish of the Draft as an RFC, request revisions, or decline to publish
as an Informational RFC in the "PDB series". as an Informational RFC in the "PDB series".
9 Acknowledgements 9 Security Considerations
The general security considerations of [RFC2474] and [RFC2475] apply
to all PDBs. Individual PDB definitions may require additional
security considerations.
10 Acknowledgements
The ideas in this document have been heavily influenced by the Diffserv The ideas in this document have been heavily influenced by the Diffserv
WG and, in particular, by discussions with Van Jacobson, Dave Clark, WG and, in particular, by discussions with Van Jacobson, Dave Clark,
Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush, Frank Kastenholz, Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush, Frank Kastenholz,
Aaron Falk, and a host of other people who should be acknowledged Aaron Falk, and a host of other people who should be acknowledged
for their useful input but not be held accountable for our mangling for their useful input but not be held accountable for our mangling
of it. Grenville Armitage coined "per domain behavior (PDB)" though of it. Grenville Armitage coined "per domain behavior (PDB)" though
some have suggested similar terms prior to that. Dan Grossman, some have suggested similar terms prior to that. Dan Grossman,
Bob Enger, Jung-Bong Suk, and John Dullaert reviewed the document Bob Enger, Jung-Bong Suk, and John Dullaert reviewed the document
and commented so as to improve its form. and commented so as to improve its form.
 End of changes. 9 change blocks. 
12 lines changed or deleted 51 lines changed or added

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