definition should be interpreted to mean "host-to-host" for
consistency.
Other PHB groups may be defined and deployed locally within domains,
for experimental or operational purposes. There is no requirement
that these PHB groups must be publicly documented, but they should
utilize DS codepoints from one of the EXP/LU pools as defined in
[DSFIELD].
G.6: It may be possible or appropriate for a packet marked for a PHB
within a PHB group to be re-marked to select another PHB within the
group; either within a domain or across a domain boundary. Typically
there are three reasons for such PHB modification:
a. The codepoints associated with the PHB group are collectively
intended to carry state about the network,
b. Conditions exist which require PHB promotion or demotion of a
packet (this assumes that PHBs within the group can be ranked in
some order),
c. The boundary between two domains is not covered by a SLA. In this
case the codepoint/PHB to select when crossing the boundary link
will be determined by the local policy of the upstream domain.
A PHB specification should clearly state the circumstances under
which packets marked for a PHB within a PHB group may, or should be
modified (e.g., promoted or demoted) to another PHB within the group.
If it is undesirable for a packet's PHB to be modified, the
specification should clearly state the consequent risks when the PHB
is modified. A possible risk to changing a packet's PHB, either
within or outside a PHB group, is a higher probability of packet re-
ordering within a microflow. PHBs within a group may carry some
host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge
semantics which may be difficult to duplicate if packets are re-
marked to select another PHB from the group (or otherwise).
For certain PHB groups, it may be appropriate to reflect a state
change in the node by re-marking packets to specify another PHB from
within the group. If a PHB group is designed to reflect the state of
a network, the PHB definition must adequately describe the
relationship between the PHBs and the states they reflect. Further,
if these PHBs limit the forwarding actions a node can perform in some
way, these constraints may be specified as actions the node should,
or must perform.
G.7: A PHB group specification should include a section defining the
implications of tunneling on the utility of the PHB group. This
section should specify the implications for the utility of the PHB
group of a newly created outer header when the original DS field of
the inner header is encapsulated in a tunnel. This section should
also discuss what possible changes should be applied to the inner
header at the egress of the tunnel, when both the codepoints from the
inner header and the outer header are accessible (see Sec. 6.2).
G.8: The process of specifying PHB groups is likely to be
incremental in nature. When new PHB groups are proposed, their known
interactions with previously specified PHB groups should be
documented. When a new PHB group is created, it can be entirely new
in scope or it can be an extension to an existing PHB group. If the
PHB group is entirely independent of some or all of the existing PHB
specifications, a section should be included in the PHB specification
which details how the new PHB group can co-exist with those PHB
groups already standardized. For example, this section might
indicate the possibility of packet re-ordering within a microflow for
packets marked by codepoints associated with two separate PHB groups.
If concurrent operation of two (or more) different PHB groups in the
same node is impossible or detrimental this should be stated. If the
concurrent operation of two (or more) different PHB groups requires
some specific behaviors by the node when packets marked for PHBs from
these different PHB groups are being processed by the node at the
same time, these behaviors should be stated.
Care should be taken to avoid circularity in the definitions of PHB
groups.
If the proposed PHB group is an extension to an existing PHB group, a
section should be included in the PHB group specification which
details how this extension interoperates with the behavior being
extended. Further, if the extension alters or more narrowly defines
the existing behavior in some way, this should also be clearly
indicated.
G.9: Each PHB specification should include a section specifying
minimal conformance requirements for implementations of the PHB
group. This conformance section is intended to provide a means for
specifying the details of a behavior while allowing for
implementation variation to the extent permitted by the PHB
specification. This conformance section can take the form of rules,
tables, pseudo-code, or tests.
G.10: A PHB specification should include a section detailing the
security implications of the behavior. This section should include a
discussion of the re-marking of the inner header's codepoint at the
egress of a tunnel and its effect on the desired forwarding behavior.
Further, this section should also discuss how the proposed PHB group
could be used in denial-of-service attacks, reduction of service
contract attacks, and service contract violation attacks. Lastly,
this section should discuss possible means for detecting such attacks
as they are relevant to the proposed behavior.
G.11: A PHB specification should include a section detailing
configuration and management issues which may affect the operation of
the PHB and which may impact candidate services that might utilize
the PHB.
G.12: It is strongly recommended that an appendix be provided with
each PHB specification that considers the implications of the
proposed behavior on current and potential services. These services
could include but are not restricted to be user-specific, device-
specific, domain-specific or end-to-end services. It is also
strongly recommended that the appendix include a section describing
how the services are verified by users, devices, and/or domains.
G.13: It is recommended that an appendix be provided with each PHB
specification that is targeted for local use within a domain,
providing guidance for PHB selection for packets which are forwarded
into a peer domain which does not support the PHB group.
G.14: It is recommended that an appendix be provided with each PHB
specification which considers the impact of the proposed PHB group on
existing higher-layer protocols. Under some circumstances PHBs may
allow for possible changes to higher-layer protocols which may
increase or decrease the utility of the proposed PHB group.
G.15: It is recommended that an appendix be provided with each PHB
specification which recommends mappings to link-layer QoS mechanisms
to support the intended behavior of the PHB across a shared-medium or
switched link-layer. The determination of the most appropriate
mapping between a PHB and a link-layer QoS mechanism is dependent on
many factors and is outside the scope of this document; however, the
specification should attempt to offer some guidance.
4. Interoperability with Non-Differentiated Services-Compliant Nodes
We define a non-differentiated services-compliant node (non-DS-
compliant node) as any node which does not interpret the DS field as
specified in [DSFIELD] and/or does not implement some or all of the
standardized PHBs (or those in use within a particular DS domain).
This may be due to the capabilities or configuration of the node. We
define a legacy node as a special case of a non-DS-compliant node
which implements IPv4 Precedence classification and forwarding as
defined in [RFC791, RFC1812], but which is otherwise not DS-
compliant. The precedence values in the IPv4 TOS octet are
compatible by intention with the Class Selector Codepoints defined in
[DSFIELD], and the precedence forwarding behaviors defined in
[RFC791, RFC1812] comply with the Class Selector PHB Requirements
also defined in [DSFIELD]. A key distinction between a legacy node
and a DS-compliant node is that the legacy node may or may not
interpret bits 3-6 of the TOS octet as defined in [RFC1349] (the
"DTRC" bits); in practice it will not interpret these bit as
specified in [DSFIELD]. We assume that the use of the TOS markings
defined in [RFC1349] is deprecated. Nodes which are non-DS-compliant
and which are not legacy nodes may exhibit unpredictable forwarding
behaviors for packets with non-zero DS codepoints.
Differentiated services depend on the resource allocation mechanisms
provided by per-hop behavior implementations in nodes. The quality
or statistical assurance level of a service may break down in the
event that traffic transits a non-DS-compliant node, or a non-DS-
capable domain.
We will examine two separate cases. The first case concerns the use
of non-DS-compliant nodes within a DS domain. Note that PHB
forwarding is primarily useful for allocating scarce node and link
resources in a controlled manner. On high-speed, lightly loaded
links, the worst-case packet delay, jitter, and loss may be
negligible, and the use of a non-DS-compliant node on the upstream
end of such a link may not result in service degradation. In more
realistic circumstances, the lack of PHB forwarding in a node may
make it impossible to offer low-delay, low-loss, or provisioned
bandwidth services across paths which traverse the node. However,
use of a legacy node may be an acceptable alternative, assuming that
the DS domain restricts itself to using only the Class Selector
Codepoints defined in [DSFIELD], and assuming that the particular
precedence implementation in the legacy node provides forwarding
behaviors which are compatible with the services offered along paths
which traverse that node. Note that it is important to restrict the
codepoints in use to the Class Selector Codepoints, since the legacy
node may or may not interpret bits 3-5 in accordance with [RFC1349],
thereby resulting in unpredictable forwarding results.
The second case concerns the behavior of services which traverse
non-DS-capable domains. We assume for the sake of argument that a
non-DS-capable domain does not deploy traffic conditioning functions
on domain boundary nodes; therefore, even in the event that the
domain consists of legacy or DS-compliant interior nodes, the lack of
traffic enforcement at the boundaries will limit the ability to
consistently deliver some types of services across the domain. A DS
domain and a non-DS-capable domain may negotiate an agreement which
governs how egress traffic from the DS-domain should be marked before
entry into the non-DS-capable domain. This agreement might be
monitored for compliance by traffic sampling instead of by rigorous
traffic conditioning. Alternatively, where there is knowledge that
the non-DS-capable domain consists of legacy nodes, the upstream DS
domain may opportunistically re-mark differentiated services traffic
to one or more of the Class Selector Codepoints. Where there is no
knowledge of the traffic management capabilities of the downstream
domain, and no agreement in place, a DS domain egress node may choose
to re-mark DS codepoints to zero, under the assumption that the non-
DS-capable domain will treat the traffic uniformly with best-effort
service.
In the event that a non-DS-capable domain peers with a DS domain,
traffic flowing from the non-DS-capable domain should be conditioned
at the DS ingress node of the DS domain according to the appropriate
SLA or policy.
5. Multicast Considerations
Use of differentiated services by multicast traffic introduces a
number of issues for service provisioning. First, multicast packets
which enter a DS domain at an ingress node may simultaneously take
multiple paths through some segments of the domain due to multicast
packet replication. In this way they consume more network resources
than unicast packets. Where multicast group membership is dynamic,
it is difficult to predict in advance the amount of network resources
that may be consumed by multicast traffic originating from an
upstream network for a particular group. A consequence of this
uncertainty is that it may be difficult to provide quantitative
service guarantees to multicast senders. Further, it may be
necessary to reserve codepoints and PHBs for exclusive use by unicast
traffic, to provide resource isolation from multicast traffic.
The second issue is the selection of the DS codepoint for a multicast
packet arriving at a DS ingress node. Because that packet may exit
the DS domain at multiple DS egress nodes which peer with multiple
downstream domains, the DS codepoint used should not result in the
request for a service from a downstream DS domain which is in
violation of a peering SLA. When establishing classifier and traffic
conditioner state at an DS ingress node for an aggregate of traffic
receiving a differentiated service which spans across the egress
boundary of the domain, the identity of the adjacent downstream
transit domain and the specifics of the corresponding peering SLA can
be factored into the configuration decision (subject to routing
policy and the stability of the routing infrastructure). In this way
peering SLAs with downstream DS domains can be partially enforced at
the ingress of the upstream domain, reducing the classification and
traffic conditioning burden at the egress node of the upstream
domain. This is not so easily performed in the case of multicast
traffic, due to the possibility of dynamic group membership. The
result is that the service guarantees for unicast traffic may be
impacted. One means of addressing this problem is to establish a
separate peering SLA for multicast traffic, and to either utilize a
particular set of codepoints for multicast packets, or to implement
the necessary classification and traffic conditioning mechanisms in
the DS egress nodes to provide preferential isolation for unicast
traffic in conformance with the peering SLA with the downstream
domain.
6. Security and Tunneling Considerations
This section addresses security issues raised by the introduction of
differentiated services, primarily the potential for denial-of-
service attacks, and the related potential for theft of service by
unauthorized traffic (Sec. 6.1). In addition, the operation of
differentiated services in the presence of IPsec and its interaction
with IPsec are also discussed (Sec. 6.2), as well as auditing
requirements (Sec. 6.3). This section considers issues introduced by
the use of both IPsec and non-IPsec tunnels.
6.1 Theft and Denial of Service
The primary goal of differentiated services is to allow different
levels of service to be provided for traffic streams on a common
network infrastructure. A variety of resource management techniques
may be used to achieve this, but the end result will be that some
packets receive different (e.g., better) service than others. The
mapping of network traffic to the specific behaviors that result in
different (e.g., better or worse) service is indicated primarily by
the DS field, and hence an adversary may be able to obtain better
service by modifying the DS field to codepoints indicating behaviors
used for enhanced services or by injecting packets with the DS field
set to such codepoints. Taken to its limits, this theft of service
becomes a denial-of-service attack when the modified or injected
traffic depletes the resources available to forward it and other
traffic streams. The defense against such theft- and denial-of-
service attacks consists of the combination of traffic conditioning
at DS boundary nodes along with security and integrity of the network
infrastructure within a DS domain.
As described in Sec. 2, DS ingress nodes must condition all traffic
entering a DS domain to ensure that it has acceptable DS codepoints.
This means that the codepoints must conform to the applicable TCA(s)
and the domain's service provisioning policy. Hence, the ingress
nodes are the primary line of defense against theft- and denial-of-
service attacks based on modified DS codepoints (e.g., codepoints to
which the traffic is not entitled), as success of any such attack
constitutes a violation of the applicable TCA(s) and/or service
provisioning policy. An important instance of an ingress node is
that any traffic-originating node in a DS domain is the ingress node
for that traffic, and must ensure that all originated traffic carries
acceptable DS codepoints.
Both a domain's service provisioning policy and TCAs may require the
ingress nodes to change the DS codepoint on some entering packets
(e.g., an ingress router may set the DS codepoint of a customer's
traffic in accordance with the appropriate SLA). Ingress nodes must
condition all other inbound traffic to ensure that the DS codepoints
are acceptable; packets found to have unacceptable codepoints must
either be discarded or must have their DS codepoints modified to
acceptable values before being forwarded. For example, an ingress
node receiving traffic from a domain with which no enhanced service
agreement exists may reset the DS codepoint to the Default PHB
codepoint [DSFIELD]. Traffic authentication may be required to
validate the use of some DS codepoints (e.g., those corresponding to
enhanced services), and such authentication may be performed by
technical means (e.g., IPsec) and/or non-technical means (e.g., the
inbound link is known to be connected to exactly one customer site).
An inter-domain agreement may reduce or eliminate the need for
ingress node traffic conditioning by making the upstream domain
partly or completely responsible for ensuring that traffic has DS
codepoints acceptable to the downstream domain. In this case, the
ingress node may still perform redundant traffic conditioning checks
to reduce the dependence on the upstream domain (e.g., such checks
can prevent theft-of-service attacks from propagating across the
domain boundary). If such a check fails because the upstream domain
is not fulfilling its responsibilities, that failure is an auditable
event; the generated audit log entry should include the date/time the
packet was received, the source and destination IP addresses, and the
DS codepoint that caused the failure. In practice, the limited gains
from such checks need to be weighed against their potential
performance impact in determining what, if any, checks to perform
under these circumstances.
Interior nodes in a DS domain may rely on the DS field to associate
differentiated services traffic with the behaviors used to implement
enhanced services. Any node doing so depends on the correct
operation of the DS domain to prevent the arrival of traffic with
unacceptable DS codepoints. Robustness concerns dictate that the
arrival of packets with unacceptable DS codepoints must not cause the
failure (e.g., crash) of network nodes. Interior nodes are not
responsible for enforcing the service provisioning policy (or
individual SLAs) and hence are not required to check DS codepoints
before using them. Interior nodes may perform some traffic
conditioning checks on DS codepoints (e.g., check for DS codepoints
that are never used for traffic on a specific link) to improve
security and robustness (e.g., resistance to theft-of-service attacks
based on DS codepoint modifications). Any detected failure of such a
check is an auditable event and the generated audit log entry should
include the date/time the packet was received, the source and
destination IP addresses, and the DS codepoint that caused the
failure. In practice, the limited gains from such checks need to be
weighed against their potential performance impact in determining
what, if any, checks to perform at interior nodes.
Any link that cannot be adequately secured against modification of DS
codepoints or traffic injection by adversaries should be treated as a
boundary link (and hence any arriving traffic on that link is treated
as if it were entering the domain at an ingress node). Local
security policy provides the definition of "adequately secured," and
such a definition may include a determination that the risks and
consequences of DS codepoint modification and/or traffic injection do
not justify any additional security measures for a link. Link
security can be enhanced via physical access controls and/or software
means such as tunnels that ensure packet integrity.
6.2 IPsec and Tunneling Interactions
The IPsec protocol, as defined in [ESP, AH], does not include the IP
header's DS field in any of its cryptographic calculations (in the
case of tunnel mode, it is the outer IP header's DS field that is not
included). Hence modification of the DS field by a network node has
no effect on IPsec's end-to-end security, because it cannot cause any
IPsec integrity check to fail. As a consequence, IPsec does not
provide any defense against an adversary's modification of the DS
field (i.e., a man-in-the-middle attack), as the adversary's
modification will also have no effect on IPsec's end-to-end security.
In some environments, the ability to modify the DS field without
affecting IPsec integrity checks may constitute a covert channel; if
it is necessary to eliminate such a channel or reduce its bandwidth,
the DS domains should be configured so that the required processing
(e.g., set all DS fields on sensitive traffic to a single value) can
be performed at DS egress nodes where traffic exits higher security
domains.
IPsec's tunnel mode provides security for the encapsulated IP
header's DS field. A tunnel mode IPsec packet contains two IP
headers: an outer header supplied by the tunnel ingress node and an
encapsulated inner header supplied by the original source of the
packet. When an IPsec tunnel is hosted (in whole or in part) on a
differentiated services network, the intermediate network nodes
operate on the DS field in the outer header. At the tunnel egress
node, IPsec processing includes stripping the outer header and
forwarding the packet (if required) using the inner header. If
the inner IP header has not been processed by a DS ingress node for
the tunnel egress node's DS domain, the tunnel egress node is the DS
ingress node for traffic exiting the tunnel, and hence must carry out
the corresponding traffic conditioning responsibilities (see Sec.
6.1). If the IPsec processing includes a sufficiently strong
cryptographic integrity check of the encapsulated packet (where
sufficiency is determined by local security policy), the tunnel
egress node can safely assume that the DS field in the inner header
has the same value as it had at the tunnel ingress node. This allows
a tunnel egress node in the same DS domain as the tunnel ingress
node, to safely treat a packet passing such an integrity check as if
it had arrived from another node within the same DS domain, omitting
the DS ingress node traffic conditioning that would otherwise be
required. An important consequence is that otherwise insecure links
internal to a DS domain can be secured by a sufficiently strong IPsec
tunnel.
This analysis and its implications apply to any tunneling protocol
that performs integrity checks, but the level of assurance of the
inner header's DS field depends on the strength of the integrity
check performed by the tunneling protocol. In the absence of
sufficient assurance for a tunnel that may transit nodes outside the
current DS domain (or is otherwise vulnerable), the encapsulated
packet must be treated as if it had arrived at a DS ingress node from
outside the domain.
The IPsec protocol currently requires that the inner header's DS
field not be changed by IPsec decapsulation processing at a tunnel
egress node. This ensures that an adversary's modifications to the
DS field cannot be used to launch theft- or denial-of-service attacks
across an IPsec tunnel endpoint, as any such modifications will be
discarded at the tunnel endpoint. This document makes no change to
that IPsec requirement.
If the IPsec specifications are modified in the future to permit a
tunnel egress node to modify the DS field in an inner IP header based
on the DS field value in the outer header (e.g., copying part or all
of the outer DS field to the inner DS field), then additional
considerations would apply. For a tunnel contained entirely within a
single DS domain and for which the links are adequately secured
against modifications of the outer DS field, the only limits on inner
DS field modifications would be those imposed by the domain's service
provisioning policy. Otherwise, the tunnel egress node performing
such modifications would be acting as a DS ingress node for traffic
exiting the tunnel and must carry out the traffic conditioning
responsibilities of an ingress node, including defense against theft-
and denial-of-service attacks (See Sec. 6.1). If the tunnel enters
the DS domain at a node different from the tunnel egress node, the
tunnel egress node may depend on the upstream DS ingress node having
ensured that the outer DS field values are acceptable. Even in this
case, there are some checks that can only be performed by the tunnel
egress node (e.g., a consistency check between the inner and outer DS
codepoints for an encrypted tunnel). Any detected failure of such a
check is an auditable event and the generated audit log entry should
include the date/time the packet was received, the source and
destination IP addresses, and the DS codepoint that was unacceptable.
An IPsec tunnel can be viewed in at least two different ways from an
architectural perspective. If the tunnel is viewed as a logical
single hop "virtual wire", the actions of intermediate nodes in
forwarding the tunneled traffic should not be visible beyond the ends
of the tunnel and hence the DS field should not be modified as part
of decapsulation processing. In contrast, if the tunnel is viewed as
a multi-hop participant in forwarding traffic, then modification of
the DS field as part of tunnel decapsulation processing may be
desirable. A specific example of the latter situation occurs when a
tunnel terminates at an interior node of a DS domain at which the
domain administrator does not wish to deploy traffic conditioning
logic (e.g., to simplify traffic management). This could be
supported by using the DS codepoint in the outer IP header (which was
subject to traffic conditioning at the DS ingress node) to reset the
DS codepoint in the inner IP header, effectively moving DS ingress
traffic conditioning responsibilities from the IPsec tunnel egress
node to the appropriate upstream DS ingress node (which must already
perform that function for unencapsulated traffic).
6.3 Auditing
Not all systems that support differentiated services will implement
auditing. However, if differentiated services support is
incorporated into a system that supports auditing, then the
differentiated services implementation should also support auditing.
If such support is present the implementation must allow a system
administrator to enable or disable auditing for differentiated
services as a whole, and may allow such auditing to be enabled or
disabled in part.
For the most part, the granularity of auditing is a local matter.
However, several auditable events are identified in this document and
for each of these events a minimum set of information that should be
included in an audit log is defined. Additional information (e.g.,
packets related to the one that triggered the auditable event) may
also be included in the audit log for each of these events, and
additional events, not explicitly called out in this specification,
also may result in audit log entries. There is no requirement for
the receiver to transmit any message to the purported sender in
response to the detection of an auditable event, because of the
potential to induce denial of service via such action.
7. Acknowledgements
This document has benefitted from earlier drafts by Steven Blake,
David Clark, Ed Ellesson, Paul Ferguson, Juha Heinanen, Van Jacobson,
Kalevi Kilkki, Kathleen Nichols, Walter Weiss, John Wroclawski, and
Lixia Zhang.
The authors would like to acknowledge the following individuals for
their helpful comments and suggestions: Kathleen Nichols, Brian
Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng,
Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, Borje
Ohlman, Alessio Casati, Scott Brim, Curtis Villamizar, Hamid Ould-
Brahi, Andrew Smith, John Renwick, Werner Almesberger, Alan O'Neill,
James Fu, and Bob Braden.
8. References
[802.1p] ISO/IEC Final CD 15802-3 Information technology - Tele-
communications and information exchange between systems -
Local and metropolitan area networks - Common
specifications - Part 3: Media Access Control (MAC)
bridges, (current draft available as IEEE P802.1D/D15).
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ATM] ATM Traffic Management Specification Version 4.0 <af-tm-
0056.000>, ATM Forum, April 1996.
[Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K.
Nichols, and M. Speer, "A Framework for Use of RSVP with
Diff-serv Networks", Work in Progress.
[DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC2474, December
1998.
[EXPLICIT] D. Clark and W. Fang, "Explicit Allocation of Best Effort
Packet Delivery Service", IEEE/ACM Trans. on Networking,
vol. 6, no. 4, August 1998, pp. 362-373.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC2406, November 1998.
[FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990.
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC791,
September 1981.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC1349, July 1992.
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: An Overview", RFC
1633, July 1994.
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", RFC1812, June 1995.
[RSVP] Braden, B., Zhang, L., Berson S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC2205, September 1997.
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997.
[TR] ISO/IEC 8802-5 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 5: Token Ring Access Method and
Physical Layer Specifications, (also ANSI/IEEE Std 802.5-
1995), 1995.
Authors' Addresses
Steven Blake
Torrent Networking Technologies
3000 Aerial Center, Suite 140
Morrisville, NC 27560
Phone: +1-919-468-8466 x232
EMail: slblake@torrentnet.com
David L. Black
EMC Corporation
35 Parkwood Drive
Hopkinton, MA 01748
Phone: +1-508-435-1000 x76140
EMail: black_david@emc.com
Mark A. Carlson
Sun Microsystems, Inc.
2990 Center Green Court South
Boulder, CO 80301
Phone: +1-303-448-0048 x115
EMail: mark.carlson@sun.com
Elwyn Davies
Nortel UK
London Road
Harlow, Essex CM17 9NA, UK
Phone: +44-1279-405498
EMail: elwynd@nortel.co.uk
Zheng Wang
Bell Labs Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
EMail: zhwang@bell-labs.com
Walter Weiss
Lucent Technologies
300 Baker Avenue, Suite 100
Concord, MA 01742-2168
EMail: wweiss@lucent.com
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.