One document matched: draft-briscoe-tsvwg-cl-phb-00.txt
TSVWG B. Briscoe
Internet Draft G. Corliano
draft-briscoe-tsvwg-cl-phb-00.txt P. Eardley
Expires: January 2006 P. Hovell
A. Jacquet
D. Songhurst
BT
July 11, 2005
The Controlled Load per hop behaviour
draft-briscoe-tsvwg-cl-phb-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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
This Internet-Draft will expire on January 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document defines two per-hop behaviours (PHBs) called Controlled
Load step and Controlled Load ramp (CL-step-PHB and CL-ramp-PHB). CL
Briscoe Expires January 11 2006 [Page 1]
Internet-Draft Controlled Load per hop behaviour July 2005
service is a quality of service (QoS) closely approximating the QoS
that same flow would receive from a lightly loaded network element
[RFC2211]. CL service is useful for inelastic flows such as those for
streaming real-time media.
Explicit Congestion Notification (ECN) marking semantics are defined
as part of the PHBs, to provide an "early warning" of potential
congestion. The PHBs can be used as a basic building block within an
edge-to-edge (CL-ramp-PHB) or end-to-end (CL-step-PHB) QoS
architecture, using distributed measurement-based admission control.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Overview and motivation......................................3
2. Detail......................................................5
2.1. Queuing................................................5
2.2. Setting the Congestion Experienced (CE) codepoint........5
2.2.1. Possible algorithms for setting the CE codepoint....6
2.3. Scheduling.............................................8
2.4. Damage limitation.......................................8
2.5. Applicability of CL PHBs................................9
2.6. Interaction with other PHBs.............................9
2.7. Interaction with default ECN behaviour..................9
2.8. Mutability............................................10
2.9. Microflow misordering..................................10
2.10. Recommended codepoint for this PHB....................10
2.11. Tunnelling...........................................10
2.12. Security Considerations...............................10
2.13. IANA considerations...................................10
3. Use cases..................................................11
3.1. Host-to-host service...................................11
3.2. Edge-to-edge service...................................11
4. Acknowledgements...........................................12
5. Comments solicited.........................................12
6. References.................................................13
Authors' Addresses............................................15
Intellectual Property Statement................................16
Disclaimer of Validity........................................17
Copyright Statement...........................................17
Briscoe Expires January 11 2006 [Page 2]
Internet-Draft Controlled Load per hop behaviour July 2005
1. Overview and motivation
Network nodes that implement the differentiated services (DS)
enhancements to IP use a codepoint in the IP header to select a per-
hop behaviour (PHB) as the specific forwarding treatment for that
packet [RFC2474, RFC2475]. This document describes two new PHBs
called Controlled Load (CL) ramp and step (CL-ramp-PHB and CL-step-
PHB).
The Quality of Service (QoS) that can be achieved with the PHBs
corresponds to the Integrated services Controlled Load (CL) class,
that is [RFC2211]: "a quality of service closely approximating the
QoS that same flow would receive from [a network element that is]
lightly loaded".
The CL PHBs are different from PHBs defined so far, in that they
define Explicit Congestion Notification (ECN) marking semantics as
part of the PHB. [RFC3168] specifies the default ECN marking
behaviour of an ECN-capable router for currently standardised PHBs,
but allows new PHBs to define different ECN marking behaviour. The
default behaviour is to indicate incipient congestion by setting the
Congestion Experienced (CE) codepoint in the IP header of packets,
with a probability determined by the RED algorithm [RFC2309] based on
the moving average queue length - so packets have their CE codepoint
set at the same point that a non-ECN-capable router would drop them.
This document specifies a different behaviour: a node sets the CE
codepoint in the IP header as an "early warning" of potential
congestion, and aims to do so before there is any significant build-
up of CL packets in the queue. This information enables appropriate
action to be taken to heed the "early warning" so that the router
should never become overloaded and forced to queue packets, and hence
the service achieves a higher performance. One example of an
'appropriate action' is that an ingress gateway blocks new microflows
(Section 3.2 and [CL-arch]). Hence it is possible for the CL packets
to suffer minimal queuing delay, jitter and loss - exactly the
requirements of real time traffic.
So a node using a CL PHB generates ECN signalling and is also part of
a system of other nodes in a closed feedback loop, which allows
control of the offered load on the local queue. To summarise: the CL
PHBs provide QoS by virtue of their local scheduling behaviour, in
combination with admission control.
The basic concepts are:
Briscoe Expires January 11 2006 [Page 3]
Internet-Draft Controlled Load per hop behaviour July 2005
o Setting the CE codepoint: the router sets the CE codepoint of CL
packets before it is actually congested (but when congestion is
fairly imminent). Reason: it enables appropriate action to be
taken so that actual congestion is not experienced, and hence a
very low loss, delay and jitter service is possible.
o Discarding: CL packets should not need to be discarded, but if
necessary packets would be discarded on a drop tail basis.
o Priority queuing: at a minimum for the CL-ramp-PHB with adaptive
bandwidth (see below), CL packets are prioritised before non-CL
packets, ie they are always de-queued first. Reason: This
minimises CL packets' delay and jitter.
o Reordering: CL packets within a flow must not be reordered, for
example this can be achieved with a first-in-first-out (FIFO)
queue. Reason: packet reordering significantly degrades the
performance of real time applications.
o Selecting the output link: the router selects the link on which to
forward the packet based on normal IP routing.
To indicate that this new behaviour is required, packets are marked
with one of two new Differentiated Services Codepoints (DSCPs). It is
hoped that (an evolution of) the CL PHBs is standardised, which
requires each PHB to have an associated RECOMMENDED DSCP. RECOMMENDED
DSCPs, rather than EXP/LU (experimental / local use) ones, enable
multi-domain operation and vendor interoperability.
Two usage scenarios are suggested in Section 3 (others are possible):
o A host-to-host service, potentially through several domains, using
the CL-step-PHB
o An edge-to-edge service across a single domain or across
cooperating domains, using the CL-ramp-PHB.
How the CL PHBs can co-exist with existing DiffServ (DS) PHBs and
with the default [RFC3168] ECN behaviour is discussed in Sections 2.6
and 2.7.
The CL PHBs - unlike the PHBs for Expedited Forwarding [RFC3246] and
Assured Forwarding [RFC2597] - do not require routers to be
configured with a minimum departure rate, although it is not
precluded.
Briscoe Expires January 11 2006 [Page 4]
Internet-Draft Controlled Load per hop behaviour July 2005
There are two CL PHB groups each of which consists of a single
individual PHB. They are intended for general or local use.
One motivation for this specification is that some network operators
are planning to carry all their traffic on a single unified network,
because this is expected to reduce operating costs dramatically.
Therefore such a network must carry real time inelastic flows like
voice and video calls, which are very delay sensitive. Per microflow
reservations are too unwieldy in the core and backbone of the
network. It is possible to achieve low delays in the core and
backbone with DS today, by triggering flow admission control when
traffic entering a DS domain exceeds its contracted rate. But for
longer topologies, the chances increase that traffic will focus on a
resource near the egress, even though it is within contract at the
ingress [Reid]. This is because the ingress contract must allow any
destination address, if it is to remain scalable. Even though
networks can be engineered to make such failures rare, when they
occur all inelastic flows through the congested resource fail
catastrophically.
2. Detail
The CL PHBs define forwarding behaviour for packets in the CL
behaviour aggregate.
2.1. Queuing
CL and non-CL packets are put into logically separate queues; if
required, a CL packet can pre-empt non-CL packet(s) in the total
buffer (see below).
2.2. Setting the Congestion Experienced (CE) codepoint
A CL implementation in a DS node MUST detect and respond to potential
congestion within the CL traffic aggregate by setting the CE
codepoint of CL packets, with a probability determined by the
algorithms described below, when it forwards them. 'Potential
congestion' means a little before the CL packets start suffering a
significant delay due to queuing in the node.
There are two PHBs with slightly different behaviour:
1. CL-step-PHB: The probability that a node sets the CE codepoint of
a packet is either 0 or 1 (ie 'on' or 'off').
Briscoe Expires January 11 2006 [Page 5]
Internet-Draft Controlled Load per hop behaviour July 2005
2. CL-ramp-PHB: The probability that a node sets the CE codepoint of
a packet can be any value.
Implementation details include the precise algorithm and the value of
its parameters.
2.2.1. Possible algorithms for setting the CE codepoint
Each node in the CL-region runs an algorithm to determine whether to
set the CE codepoint of a particular CL packet. In our description we
assume that a bulk token bucket is used (note that there is not a
token bucket per microflow). Tokens are added when packets are queued
and are consumed at a fixed rate. The idea is that an excess of
tokens is seen before the queue of CL packets has got long enough to
cause the CL packets to suffer a significant delay - the algorithms
are explained more fully below and are slightly different for the CL-
step-PHB and CL-ramp-PHB. Other implementations are possible.
The two CL PHBs use different algorithms for determining how the
amount of tokens whether a packet has its CE codepoint set:
1. CL-step: The CE codepoint setting is either 'on' or 'off'. As soon
as the amount of tokens is greater than a threshold value, then
all CL-step packets have their CE codepoint set. To prevent
instability, the metering function has built-in hysterisis, ie
this continues until the amount of tokens has decreased below a
second threshold value.
2. CL-ramp: There are two alternatives described in detail in [CL-
arch]:
o Configured bandwidth: the node has a fixed maximum bandwidth
allocated to CL-ramp traffic, under the control of management
configuration. Tokens are consumed slightly slower than this rate.
The probability that a node sets the CE codepoint of a CL-ramp
packet depends on the number of tokens in the bucket. Below one
threshold value of the number of tokens no packets have their CE
codepoint set and above the second they all do; in between, the
probability increases linearly.
Briscoe Expires January 11 2006 [Page 6]
Internet-Draft Controlled Load per hop behaviour July 2005
o Flexible bandwidth: the node allows an adaptive trade-off between
CL-ramp and non-CL-ramp traffic. Tokens are consumed at slightly
less than the (total) outgoing service rate. The probability that
a node sets the CE codepoint of a CL packet depends on the number
of tokens in the bucket *plus* the number of queued non-CL
packets. Below one threshold value of this sum no packets have
their CE codepoint set and above the second they all do; in
between, the probability increases linearly.
In the flexible bandwidth case, the probability reflects the load of
both CL and non-CL traffic. The reason is to ensure a 'fair balance'
between the two classes, by rejecting CL session requests if non-CL
demand is very high. Alternatively, if the number of queued non-CL
packets is not included, then the admission of a CL microflow is
independent of the amount of non-CL traffic.
Probability
of setting ^
CE codepoint |
|
1_| ____<____
| | |
| | |
| | |
| | |
| | ^
| | |
| | |
| | |
| | |
0_|___________|____>____|
|
-----------|---------|-------------->
min- max- Amount of tokens
threshold threshold
Figure 1: Setting Congestion Experienced Codepoint for CL-step-PHB
Briscoe Expires January 11 2006 [Page 7]
Internet-Draft Controlled Load per hop behaviour July 2005
Probability
of setting ^
CE codepoint |
|
1_| _______________
| /
| /
| /
| /
| /
| /
| /
| /
| /
0_|___________/
|
-----------|---------|-------------->
min- max- Amount of tokens
threshold threshold + number of queued
non-CL packets
Figure 2: Setting Congestion Experienced Codepoint for CL-ramp-PHB
2.3. Scheduling
In the CL-ramp case with flexible bandwidth, CL packets are always
scheduled ahead of non-CL ones, in order to minimise their delay and
jitter, and FIFO (First In First Out) scheduling is used to prevent
reordering within a CL microflow. This is needed because the arrival
rate of CL packets is unknown. The fixed bandwidth case has more
options, for example the CL-ramp and non-CL traffic could be serviced
by a Weighted Round Robin scheduler.
2.4. Damage limitation
It is expected that setting the CE codepoint will enable appropriate
action to be taken early enough to prevent significant congestion.
However, in some circumstances (for instance if a node fails) it will
not be sufficient. Therefore, if a CL PHB is implemented by a
mechanism that allows unlimited pre-emption of other traffic (eg a
Briscoe Expires January 11 2006 [Page 8]
Internet-Draft Controlled Load per hop behaviour July 2005
priority queue), the implementation SHOULD include some means to
limit the damage CL traffic could inflict on other traffic.
2.5. Applicability of CL PHBs
It is suggested that the CL-step-PHB is defined for probing. One
advantage of the CL-step-PHB is that it sets the CE codepoint
immediately it notices there is potential congestion, so the
admission control can react to a single CE packet.
It is suggested that the CL-ramp-PHB is defined for either data or
probing. Advantages of the CL-ramp-PHB are that it can discriminate
between different levels of congestion and accumulate the congestion
signal across the network (so it can detect when several nodes are
experiencing a low level of congestion such that a step algorithm
would be 'off' in all nodes).
Use cases for the CL PHBs are briefly described in Section 3.
2.6. Interaction with other PHBs
Other PHBs and PHB groups may be deployed in the same DS node or
domain with a CL PHB. CL traffic is prioritised over all other PHBs,
but the admission control procedure prevents the CL traffic affecting
their service.
It is believed that the CL-ramp-PHB configured and flexible bandwidth
cases belong to the same PHB because they can both be used in the
same domain, since the difference between them doesn't affect the way
the ingress and egress nodes do admission control and metering.
It is believed that the CL-step-PHB and CL-ramp-PHB are different
PHBs, because they cannot be used within the same domain, since the
CE codepoint is interpreted differently. With the CL-step-PHB a
single CE packet can cause the admission controller to block a new
microflow, whereas with the CL-ramp-PHB sufficient packets are needed
to estimate the congestion level. However, it would be possible to
use CL-step-PHB for probe traffic and CL-ramp-PHB for data traffic
within the same domain.
2.7. Interaction with default ECN behaviour
The CL PHBs define behaviour for setting the CE codepoint that is
different from the default ECN marking behaviour [RFC3168]. To
address the concerns of [Floyd] it therefore must be ensured that the
packets only travel through nodes with a CL PHB. This could be done
by signalling (to verify that the nodes on the path all understand
Briscoe Expires January 11 2006 [Page 9]
Internet-Draft Controlled Load per hop behaviour July 2005
the CL PHB) or by configuration (eg in usage scenario 2 the whole
domain runs the CL-ramp-PHB).
2.8. Mutability
CL packets with the ECN field cleared (`Not ECT') should be re-marked
to Best Effort. In most scenarios, all CL packets should be ECN-
capable, so it MAY be appropriate to raise a suitable management
alarm the first time this is not the case.
In the edge-to-edge usage scenario, which is described below in
Section 3.2, if some packets of a CL microflow are over the
reservation at the ingress edge, then they SHOULD be marked to Best
Effort.
2.9. Microflow misordering
Packets that belong to a single microflow within the CL behaviour
aggregate passing through a device SHOULD NOT be re-ordered in normal
operation of the device. In a microflow where packets are marked to
Best Effort by the ingress node (see Mutability sub-section) they may
become misordered, but note that these packets are never part of the
CL behaviour aggregate.
2.10. Recommended codepoint for this PHB
Codepoint xxxxxx is RECOMMENDED for the CL-ramp-PHB and codepoint
xxxxxx is RECOMMENDED for the CL-step-PHB. RECOMMENDED codepoints are
needed, rather than EXP/LU ones, to enable host-to-host and inter-
operator usage.
2.11. Tunnelling
When CL packets are tunnelled, the tunnelling packets SHOULD be
marked as CL and the ECN field copied between headers as in RFC3168.
2.12. Security Considerations
TBD
2.13. IANA considerations
TBD.
Briscoe Expires January 11 2006 [Page 10]
Internet-Draft Controlled Load per hop behaviour July 2005
3. Use cases
Two possible usage scenarios for the CL PHBs are discussed in this
section:
o A host-to-host service, potentially through several domains
o An edge-to-edge service across a single domain or across
cooperating domains.
3.1. Host-to-host service
This usage scenario is based on [RTECN-usage]. A source wanting to
establish a real time inelastic microflow sends probe packets, which
have their DSCP set to the value for the CL-step-PHB and the ECN
field set to the ECT codepoint. Nodes en route set the CE codepoint
if necessary as an "early warning" of potential congestion. The
receiver informs the source about the value(s) of the ECN field of
the probe packets, enabling the source to decide whether or not the
new microflow is acceptable. To ease migration, [RTECN] suggests that
to start with the mechanism is deployed in a limited number of nodes
- those known to be points where the bandwidth is constrained.
3.2. Edge-to-edge service
This usage scenario is described more fully in [CL-arch]. The CL-
ramp-PHB is used within a single domain. The ingress node to the
domain sets the DSCP to the value for the CL-ramp-PHB and the ECN
field set to the ECT codepoint. Nodes en route set the CE codepoint
if necessary as an "early warning" of potential congestion. The
egress node of the domain meters CL-ramp packets that have their CE
codepoint set. It calculates the fraction of the total (CL-ramp) bits
that are in CE packets. The calculation is done as an exponentially
weighted moving average ('Congestion-Level-Estimate'). Congestion-
Level-Estimate provides an estimate of how near the domain is getting
to a load where the CL-ramp traffic will start suffering significant
delays. Note that the metering and calculation are done separately
for CL-ramp packets from each ingress router, because (as discussed
in Section 1) there may be sufficient capacity on all the nodes on
the path between one ingress node and a particular egress, but not
from a second ingress.
Briscoe Expires January 11 2006 [Page 11]
Internet-Draft Controlled Load per hop behaviour July 2005
In order to decide whether to admit a new real time inelastic
microflow, the current value for Congestion-Level-Estimate is
compared with a threshold value; if it is greater then the request is
refused, otherwise it is accepted. It would be possible to have
different service priorities (eg for emergency calls or important
users) by the ingress having different thresholds for Congestion-
Level-Estimate.
The details depend on the end-to-end signalling protocol, but for
example with RSVP, Congestion-Level-Estimate is included as an opaque
object within the RESV message. If the current value for Congestion-
Level-Estimate is unknown (eg if there are no microflows at present
between the relevant ingress and egress nodes), then probe packets
are sent, from which the egress node can initialise its meter. These
probe packets could use either the CL-ramp-PHB or the CL-step-PHB.
It is also possible for several adjacent domains to cooperate. Then
only the ingress and egress nodes of the combined region take part in
the admission control procedure; border nodes within the combined
region do not take part in signal processing or hold path state. The
domains can even be run by different operators; in this case the
border routers between operators only have to do bulk accounting -
per microflow metering and policing is not needed [Briscoe].
4. Acknowledgements
We thank Joe Babiarz for very helpful discussion about this document
and [RTECN].
This work evolved from the Guaranteed Stream Provider developed in
the M3I project [GSPa, GSP-TR], which in turn was based on the
theoretical work of Gibbens and Kelly [DCAC].
5. Comments solicited
Comments and questions are encouraged and very welcome. They can be
sent to the Transport Area Working Group's mailing list,
tsvwg@ietf.org, and/or to the authors (either individually or
collectively at gqs@jungle.bt.co.uk).
Briscoe Expires January 11 2006 [Page 12]
Internet-Draft Controlled Load per hop behaviour July 2005
6. References
A later version will distinguish normative and informative
references.
[Briscoe] Bob Briscoe and Steve Rudkin, "Commercial Models for
IP Quality of Service Interconnect", BT Technology
Journal, Vol 23 No 2, April 2005.
[CL-arch] B. Briscoe, G. Corliano, P. Eardley, P. Hovell, A.
Jacquet, D. Songhurst, 'An architecture for edge-to-
edge controlled load service using distributed
measurement-based admission control', draft-briscoe-
tsvwg-cl-architecture-00.txt", (work in progress),
July 2005
[DCAC] Richard J. Gibbens and Frank P. Kelly "Distributed
connection acceptance control for a connectionless
network", In: Proc. International Teletraffic Congress
(ITC16), Edinburgh, pp. 941ù952 (1999).
[Floyd] S. Floyd, 'Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field', draft-
floyd-ecn-alternates-00.txt (work in progress), April
2005
[GSPa] Karsten (Ed.), Martin "GSP/ECN Technology \&
Experiments", Deliverable: 15.3 PtIII, M3I Eu Vth
Framework Project IST-1999-11429, URL:
http://www.m3i.org/ (February, 2002) (superseded by
[GSP- TR])
[GSP-TR] Martin Karsten and Jens Schmitt, "Admission Control
Based on Packet Marking and Feedback Signalling ¡--
Mechanisms, Implementation and Experiments", TU-
Darmstadt Technical Report TR-KOM-2002-03, URL:
http://www.kom.e-technik.tu-
darmstadt.de/publications/abstracts/KS02-5.html (May,
2002)
[Reid] ABD Reid, 'Economics and scalability of QoS
solutions', BT Technology Journal, Vol 23 No 2, April
2005
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Briscoe Expires January 11 2006 [Page 13]
Internet-Draft Controlled Load per hop behaviour July 2005
[RFC2211] J. Wroclawski, Specification of the Controlled-Load
Network Element Service, September 1997
[RFC2309] Braden, B., et al., "Recommendations on Queue
Management and Congestion Avoidance in the Internet",
RFC 2309, April 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z. and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3246] B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le
Boudec, W. Courtney, S. Davari, V. Firoiu, D.
Stiliadis, 'An Expedited Forwarding PHB (Per-Hop
Behavior)', RFC 3246, March 2002.
[RTECN] Babiarz, J., Chan, K. and V. Firoiu, 'Congestion
Notification Process for Real-Time Traffic', draft-
babiarz-tsvwg-rtecn-03" Work in Progress, February
2005.
[RTECN-usage] Alexander, C., Ed., Babiarz, J. and J. Matthews,
'Admission Control Use Case for Real-time ECN, draft-
alexander-rtecn-admission-control-use-case-00', Work
in Progress, February 2005.
[vq] Costas Courcoubetis and Richard Weber "Buffer Overflow
Asymptotics for a Switch Handling Many Traffic
Sources" In: Journal Applied Probability 33 pp. 886--
903 (1996).
Briscoe Expires January 11 2006 [Page 14]
Internet-Draft Controlled Load per hop behaviour July 2005
Authors' Addresses
Bob Briscoe
BT Research
B54/77, Sirius House
Adastral Park
Martlesham Heath
Ipswich, Suffolk
IP5 3RE
United Kingdom
Email: bob.briscoe@bt.com
Dave Songhurst
BT Research
B54/69, Sirius House
Adastral Park
Martlesham Heath
Ipswich, Suffolk
IP5 3RE
United Kingdom
Email: dsonghurst@jungle.bt.co.uk
Philip Eardley
BT Research
B54/77, Sirius House
Adastral Park
Martlesham Heath
Ipswich, Suffolk
IP5 3RE
United Kingdom
Email: philip.eardley@bt.com
Peter Hovell
BT Research
B54/69, Sirius House
Adastral Park
Martlesham Heath
Ipswich, Suffolk
IP5 3RE
United Kingdom
Email: peter.hovell@bt.com
Briscoe Expires January 11 2006 [Page 15]
Internet-Draft Controlled Load per hop behaviour July 2005
Gabriele Corliano
BT Research
B54/70, Sirius House
Adastral Park
Martlesham Heath
Ipswich, Suffolk
IP5 3RE
United Kingdom
Email: gabriele.2.corliano@bt.com
Arnaud Jacquet
BT Research
B54/70, Sirius House
Adastral Park
Martlesham Heath
Ipswich, Suffolk
IP5 3RE
United Kingdom
Email: arnaud.jacquet@bt.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org
Briscoe Expires January 11 2006 [Page 16]
Internet-Draft Controlled Load per hop behaviour July 2005
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Briscoe Expires January 11 2006 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-22 06:03:12 |