Internet DRAFT - draft-alexander-congestion-status-preconditions
draft-alexander-congestion-status-preconditions
Session Initiation Proposal C. Alexander, Ed.
Investigation J. Rutledge
Internet-Draft Nortel
Expires: April 26, 2006 October 23, 2005
A Congestion Status Precondition for the Session Initiation Protocol
(SIP)
draft-alexander-congestion-status-preconditions-01.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 April 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines the Congestion Status precondition for SIP,
utilizing the framework defined in RFC 3312 and updated in RFC 4032.
The Congestion Status precondition requires that the participant
verify that congestion thresholds along the network path for the
session media have not been exceeded before continuing with session
establishment or modification. This verification is performed via an
RTP probe utilizing draft "Congestion Notification Process for Real-
Alexander & Rutledge Expires April 26, 2006 [Page 1]
Internet-Draft Congestion Status Precondition October 2005
Time Traffic" and draft "RTP Payload Format for ECN Probing".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. History . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Alternatives Under Consideration . . . . . . . . . . . . . . 7
5.1 Define a New Precondition . . . . . . . . . . . . . . . . 7
5.2 Re-use QoS Precondition . . . . . . . . . . . . . . . . . 7
5.3 No Explicit Precondition Signaling . . . . . . . . . . . . 7
6. Congestion Status Precondition Definition . . . . . . . . . 9
6.1 Precondition Type Tag . . . . . . . . . . . . . . . . . . 9
6.2 Additional Data Type . . . . . . . . . . . . . . . . . . . 9
6.3 Payload Type . . . . . . . . . . . . . . . . . . . . . . . 9
6.4 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 10
6.5 Status Type . . . . . . . . . . . . . . . . . . . . . . . 10
6.6 Precondition Strength . . . . . . . . . . . . . . . . . . 10
6.7 Direction Tag . . . . . . . . . . . . . . . . . . . . . . 10
6.8 Suspending and Resuming Session Establishment . . . . . . 10
6.9 Cessation of ECN Probing . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1 Normative References . . . . . . . . . . . . . . . . . . 19
10.2 Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . 21
Alexander & Rutledge Expires April 26, 2006 [Page 2]
Internet-Draft Congestion Status Precondition October 2005
1. Introduction
RFC 3312 [2], updated by RFC 4032 [3], defines the basic concept of
preconditions, and a framework through which new preconditions can be
defined. This document defines a new Congestion Status precondition,
"cong", that provides an admission control mechanism based on whether
there is congestion in the network.
An entity can use the Congestion Status precondition to delay session
establishment or modification until a determination can be made that
congestion thresholds along the network path between the offerer and
answerer have not been exceeded. When a mandatory Congestion Status
precondition is received in an offer, session establishment or
modification MUST be delayed until the Congestion Status precondition
has been met, i.e., the Explicit Congestion Notification (ECN) value
in ECN probe packets, as defined in "RTP Payload Format for ECN
Probing" [6], explicitly indicates that congestion thresholds along
the network path for the new session media have not been exceeded.
The Congestion Status precondition relies on "Congestion Notification
Process for Real-Time Traffic" [5] to be implemented within select
routers in the network, specifically those routers at which
congestion is likely to occur. It also relies on [6] and "Real-time
ECN Use Cases" [7] for the end-systems to probe for congestion. The
probe streams received at each end-system are analyzed, and the ECN
markings are used to either pass or fail the preconditions.
Alexander & Rutledge Expires April 26, 2006 [Page 3]
Internet-Draft Congestion Status Precondition October 2005
2. History
2.1 Version 00
Initial submission.
2.2 Version 01
Adding section outlining alternatives under consideration. No other
major content changes over -00 version.
Alexander & Rutledge Expires April 26, 2006 [Page 4]
Internet-Draft Congestion Status Precondition October 2005
3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC2119 [15] and
indicate requirement levels for compliant implementations.
Alexander & Rutledge Expires April 26, 2006 [Page 5]
Internet-Draft Congestion Status Precondition October 2005
4. Definitions
The following terms are used in this document, many adopted directly
from RFC 3264 [4]:
Agent: An agent is the protocol implementation involved in the offer/
answer exchange. There are two agents involved in an offer/answer
exchange.
Answer: An SDP message sent by an answerer in response to an offer
received from an offerer.
Answerer: An agent which receives a session description from another
agent describing aspects of desired media communication, and then
responds to that with its own session description.
ECN Probe Stream: [7] describes a stream of RTP packets whose payload
consists of that described in [6]. The ECN probe stream is used
to detect congestion in the network via the mechanisms described
in [5].
Media Stream: As defined in RFC 2326 [11], a media stream is a single
media instance, e.g., an audio stream or a video stream as well as
a single whiteboard or shared application group. In SDP, a media
stream is described by an "m=" line and its associated attributes.
Offer: An SDP message sent by an offerer.
Offerer: An agent which generates a session description in order to
create or modify a session.
Alexander & Rutledge Expires April 26, 2006 [Page 6]
Internet-Draft Congestion Status Precondition October 2005
5. Alternatives Under Consideration
There are multiple ways to provide a precondition capability for the
Real-time ECN mechanism for admission control. These will be
outlined here, with the intent to describe the known issues and
concerns with each approach. As this document is still evolving, one
of these alternatives, or perhaps another alternative not described
here, will ultimately be chosen as the best approach.
5.1 Define a New Precondition
The overall content of this document takes this approach. The
advantage of this approach is that the precondition is specifically
tied to the Real-time ECN mechanism, and in no way should it be
confused with other admission control mechanisms.
5.2 Re-use QoS Precondition
This alternative was suggested as being preferred over defining a new
precondition. The reasoning is understood to be that the QoS
precondition was defined for just such purposes, and that a new
precondition is simply not necessary. We are interested in pursuing
this approach, but at this time perceive that the QoS precondition as
defined in RFC 3312 [2] and RFC 4032 [3] is ambiguous with respect to
how it is tied to specific mechanisms.
At issue is whether the QoS precondition is tied to RSVP. While this
may not have been the intent with its introduction, this can be very
easily interpreted from its specification. Based on this
interpretation, the concern with re-using the QoS precondition for
Real-time ECN is that there may be interoperability issues whereby
two devices utilize the QoS precondition, but with each supposing and
using a different underlying mechanism.
The best alternative would be for the QoS precondition to be extended
to include a mechanism for negotiation of the mechanism triggered by
the precondition. This document does not define such an extension,
but were such an extension to be defined, this document would be
changed appropriately to utilize it.
5.3 No Explicit Precondition Signaling
It is possible to specify that the mechanism of delaying user-
indication of a new session during admission control for Real-time
ECN be implicitly built into a device without requiring the need for
explicit signaling to that effect. The major advantage to this
approach is that, because there is less signaling involved to relay
whether the precondition is met, what some may consider to be a
Alexander & Rutledge Expires April 26, 2006 [Page 7]
Internet-Draft Congestion Status Precondition October 2005
significant delay in call setup is avoided. The disadvantage is
perhaps one of mere perception, in that no explicit signaling is
involved.
Alexander & Rutledge Expires April 26, 2006 [Page 8]
Internet-Draft Congestion Status Precondition October 2005
6. Congestion Status Precondition Definition
The Congestion Status precondition type is represented by "cong".
6.1 Precondition Type Tag
The precondition-type tag for the Congestion Status precondition is
"cong". The resulting precondition-type grammar refined from that
defined in [2] is:
precondition-type = "cong" | "qos" | token
6.2 Additional Data Type
A new type, additional-data, is defined for the desired-status
attribute. It is generically specified as follows:
additional-data = ""
This tag allows preconditions to extend the desired-status attribute
line with data specific to their function and behavior, while keeping
the tag itself generic to any precondition that requires its use.
6.3 Payload Type
[6] specifies a dynamic payload type for the ECN probe packets in an
ECN probe stream. The dynamic payload type values are defined in RFC
3551 [12]. This will be specified on the desired-status line of the
Congestion Status precondition as a value within the additional-data
type. For the specification of this value, a new type, payload-type,
is defined for use with this precondition. This also necessitates
the modification of the additional-data type defined earlier. The
payload-type type is REQUIRED for the Congestion Status precondition.
additional-data = "" | payload-type
payload-type = 96-127
The payload-type value specified in the initial INVITE offer
specifying the Congestion Status precondition indicates the payload
type the offerer and/or answerer will use to identify ECN probe
packets in an ECN probe stream. It SHOULD be used as the payload-
type value in any ECN probe flows associated with the corresponding
media type. If the corresponding answer indicates a different
payload-type value than that in the offer, then the payload-type
value in the offer indicates the payload-type value the offerer
expects to see for ECN probe packets it receives, and the payload-
type value in the answer indicates the payload-type value the
Alexander & Rutledge Expires April 26, 2006 [Page 9]
Internet-Draft Congestion Status Precondition October 2005
answerer expects to see for ECN probe packets it receives.
6.4 SDP Parameters
Based on the new precondition-type value, and the new additional-data
and payload-type types, the SDP parameters specified in [2] are
modified as follows:
desired-status = "a=des" precondition-type
SP strength-tag SP status-type
SP direction-tag SP additional-data
precondition-type = "cong" | "qos" | token
additional-data = "" | payload-type
payload-type = 96-127
6.5 Status Type
The Congestion Status precondition MUST support the end-to-end status
type as defined in [2]. An implementation MAY support the segmented
status types.
6.6 Precondition Strength
The Congestion Status precondition is defined as a mandatory
precondition. Note that use of a mandatory precondition requires the
presence of a Require header with the option tag "precondition".
6.7 Direction Tag
As described in [2], the direction tags represent the point of view
of the entity generating the SDP description. For example, in an
offer, "send" is the direction offerer->answerer, while in an answer,
"send" is the direction answerer->offerer.
6.8 Suspending and Resuming Session Establishment
When the preconditions requirement is accepted by the answerer,
session setup is suspended until the preconditions are met or fail.
During this suspension of session setup, neither the offerer or
answerer provide any type of ringing.
The Congestion Status precondition allows one or both of the offerer
and answerer to verify during session setup, before ringing begins,
that there is adequate bandwidth available in the network for the
associated session media. It utilizes the probe payload defined in
[6], and a probing mechanism such as that desribed in [7], to probe
for congestion in the network. If the probe indicates that the
Alexander & Rutledge Expires April 26, 2006 [Page 10]
Internet-Draft Congestion Status Precondition October 2005
congestion thresholds along the network path have not been exceeded,
the preconditions are met. Otherwise, they are failed.
In the example SDPs that follow, note that there is no rtpmap
attribute in the SDP associated with ECN probing. This is because
the probing mechanism and payload format are implicitly linked to the
Congestion Status precondition, as can be seen by the payload-type
value associated with the desired-status attribute of this
precondition. Only the rtpmap attribute for the session media is
explicitly described in the SDP.
[6] also describes that the probe flow can optionally mimic various
properties of the session media, specifically the send rate. This is
determined implicitly, as well, based on the preferred media
specified in the SDP.
Offerer Answerer
| |
|------------ (1) INVITE SDP1 -------------->|
| |
|<----- (2) 183 Session Progress SDP2 -------|
| |
|<========= (3) RTP Probe Flow ==============|
| |
|========== (4) RTP Probe Flow =============>|
| |
|--------------- (5) PRACK ----------------->|
| |
|<---------- (6) 200 OK (PRACK) -------------|
| |
|------------ (7) UPDATE SDP3 -------------->|
| |
|<------- (8) 200 OK (UPDATE) SDP4 ----------|
| |
|<------------ (9) 180 Ringing --------------|
| |
|---------------- (10) PRACK --------------->|
| |
|<----------- (11) 200 OK (PRACK) -----------|
| |
| |
| |
|<---------- (12) 200 OK (INVITE) -----------|
| |
|----------------- (13) ACK ---------------->|
| |
Alexander & Rutledge Expires April 26, 2006 [Page 11]
Internet-Draft Congestion Status Precondition October 2005
In SDP1, the offerer specifies a mandatory end-to-end Congestion
Status precondition with "sendrecv" as the desired status. "sendrecv"
indicates that congestion must be checked in both the send and
receive direction, from the point of view of the offerer. The
offerer's local status table is:
Direction | Current | Desired Strength | Confirm
-----------+-----------+------------------+---------
send | no | mandatory | no
recv | no | mandatory | no
The SDP content for SDP1 is:
m=audio 50002 RTP/AVP 0 8 18
c=IN IP4 192.168.1.200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=curr:cong e2e none
a=des:conn mandatory e2e sendrecv 104
SDP1 carries to the answerer the IP address and port number for the
offerer. Note that the value 104 is specified on the desired-status
line as the payload-type value that the offerer expects to see for
ECN probe packets.
Once the offerer sends SDP1, it MUST begin listening for probe
packets on the IP address and port number associated with the
Congestion Status precondition in SDP1.
In SDP2, the answerer responds indicating that it wants the offerer
to inform it about the congestion status in the network from the
answerer to the offerer. The answerer's local status table is:
Direction | Current | Desired Strength | Confirm
-----------+-----------+------------------+---------
send | no | mandatory | no
recv | no | mandatory | no
The answerer indicates that it wants the offerer to inform it about
congestion from the answerer to the offerer by using the confirm-
status attribute. The SDP content for SDP2 is:
Alexander & Rutledge Expires April 26, 2006 [Page 12]
Internet-Draft Congestion Status Precondition October 2005
m=audio 51286 RTP/AVP 0 8 18
c=IN IP4 192.168.1.235
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=curr:cong e2e none
a=des:conn mandatory e2e sendrecv 104
a=conf:cong e2e send
SDP2 carries to the offerer the IP address and port number for the
answerer. Note that the value 104 is specified on the desired-status
line, unchanged from SDP1, as the payload-type value the answerer
expects to see for ECN probe packets.
Once the answerer sends SDP2, it MUST begin listening for probe
packets on the IP address and port number associated with the
Congestion Status precondition in SDP2. It MUST also begin
generating a stream of probe packets to the IP address and port
number for the offerer that it determined from SDP1. The probe
packets MUST adhere to the format defined in [6], optionally padded
to a size corresponding to the codec to be used for session media.
When the offerer receives SDP2, it updates its local status table to
reflect the confirm-status attribute as follows:
Direction | Current | Desired Strength | Confirm
-----------+-----------+------------------+---------
send | no | mandatory | no
recv | no | mandatory | yes
The offerer MUST also begin generating a stream of probe packets to
the IP address and port number for the answerer that it determined
from SDP2. The probe packets MUST adhere to the format defined in
[6], optionally padded to a size corresponding to the codec to be
used for session media.
Both the offerer and answerer, upon receiving the stream of probe
packets, determines whether congestion is present in the network by
applying [5].
As the offerer receives the stream of probe packets from the answerer
indicating that congestion thresholds along the network path have not
been exceeded, the offerer's local status table is updated to:
Direction | Current | Desired Strength | Confirm
-----------+-----------+------------------+---------
send | no | mandatory | no
recv | yes | mandatory | yes
Alexander & Rutledge Expires April 26, 2006 [Page 13]
Internet-Draft Congestion Status Precondition October 2005
As the answerer receives the stream of probe packets from the offerer
indicating that congestion thresholds along the network path have not
been exceeded, the answerer's local status table is updated to:
Direction | Current | Desired Strength | Confirm
-----------+-----------+------------------+---------
send | no | mandatory | no
recv | yes | mandatory | no
The answerer now waits on the offerer to confirm the congestion
status in the network from the answerer to the offerer. The offerer
generates and sends SDP3 in an UPDATE request as follows:
m=audio 50002 RTP/AVP 0 8 18
c=IN IP4 192.168.1.200
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=curr:cong e2e recv
a=des:conn mandatory e2e sendrecv 104
The answerer uses SDP3 to update its local status table as follows:
Direction | Current | Desired Strength | Confirm
-----------+-----------+------------------+---------
send | yes | mandatory | no
recv | yes | mandatory | no
Should the UPDATE request from the offerer arrive at the answerer
before the stream of probe packets from the offerer, the answerer
sends a 500 Server Internal Error response with the Retry-After
header indicating the request should be attempted again in 1-3
seconds.
At this point, the Congestion Status precondition has been
successfully met. The answerer responds with SDP4 as follows:
m=audio 51286 RTP/AVP 0 8 18
c=IN IP4 192.168.1.235
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=curr:cong e2e sendrecv
a=des:conn mandatory e2e sendrecv 104
As the Congestion Status precondition has now been met, ringing
begins with the answerer sending a 180 Ringing response.
Alexander & Rutledge Expires April 26, 2006 [Page 14]
Internet-Draft Congestion Status Precondition October 2005
6.9 Cessation of ECN Probing
The ECN probe stream(s) generated as a result of the Congestion
Status precondition MAY be terminated by the answer after receiving
an UPDATE request from the offerer containing SDP3 and/or by the
offerer after receiving either a 200 UPDATE response from the
answerer containing SDP4, or a 580 Precondition Failure final
response.
Alternatively, the ECN probe stream(s) MAY continue to be generated
after preconditions are met successfully. In this case, the ECN
probe stream(s) started after the 183 Session Progress message was
sent/received MAY continue to be sent, until either session
establishment is aborted via a CANCEL from the offerer or a final
response from the answerer, or the session is established. The
agents MUST continue to monitor the ECN probe stream(s) for network
congestion. If detected, local policy will be used to dictate the
action to be taken. The typical action upon detection of congestion
is to terminate the session setup with a CANCEL message if congestion
is detected by the offerer, or a 503 Service Unavailable final
response if detected by the answerer.
If the session is established, both the offerer and/or answerer
SHOULD stop sending their respective ECN probe stream(s), and
immediately begin sending session media. The answerer MAY do this as
soon as it sends the 200 OK indicating that the session is
established. The offerer MAY do this as soon as it receives the 200
OK indicating that the session was established.
Alexander & Rutledge Expires April 26, 2006 [Page 15]
Internet-Draft Congestion Status Precondition October 2005
7. Security Considerations
[2] and [3] describe security considerations for preconditions. In
addition, security considerations specific to the Congestion Status
precondition are described here.
[5] and [6] describe security considerations for the Real-time ECN
mechanism and the associated RTP payload format. They consider the
possibility of devices attempting to change the level of congestion
reported by the ECN probe stream, and describe mechanisms to detect
such changes.
Similar to the recommendations in [5] and [6], the RTP packets in the
ECN probe stream(s) SHOULD be secured, and the SIP/SDP messaging
SHOULD also be secured with S/MIME [8] or TLS [9], [10].
This precondition utilizes an RTP stream - the ECN probe stream - to
detect congestion during session setup. A denial of service attack
is possible, but harbors little more risk than for any other RTP
media stream. The ECN probe stream is only generated during session
setup, prior to answer, so the agents involved only listen and expect
such a stream during this time. [5] discusses the possibility of a
denial of service attack in which false congestion is reported.
Alexander & Rutledge Expires April 26, 2006 [Page 16]
Internet-Draft Congestion Status Precondition October 2005
8. IANA Considerations
This document extends the desired-status SDP attribute defined in [2]
with two new types, additional-data and payload-type. These are
described in Section 6.2 and Section 6.3.
This document defines the following precondition, with the request
that it be registered by the IANA:
Precondition-Type Reference Description
----------------- ------------- ------------------------------
cong This document Congestion Status precondition
Alexander & Rutledge Expires April 26, 2006 [Page 17]
Internet-Draft Congestion Status Precondition October 2005
9. Acknowledgements
The authors acknowledge a great many inputs, including the following:
Francois Audet, Jeremy Matthews, and Stephen Dudley.
Alexander & Rutledge Expires April 26, 2006 [Page 18]
Internet-Draft Congestion Status Precondition October 2005
10. References
10.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Camarillo, G., Marshall, B., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)",
RFC 3312, June 2002.
[3] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation
Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Babiarz, J., Chan, K., and V. Firoiu, "Congestion Notification
Process for Real-Time Traffic", Internet-Draft
draft-babiarz-tsvwg-rtecn-04.txt (Work in Progress), July 2005.
[6] Alexander, C., Ed. and J. Babiarz, "RTP Payload Format for ECN
Probing", Internet-Draft
draft-alexander-rtp-payload-for-ecn-probing-02.txt (Work in
Progress), October 2005.
10.2 Informative References
[7] Alexander, C., Ed., Babiarz, J., and J. Matthews, "Real-time
ECN Use Cases", Internet-Draft
draft-alexander-rtecn-use-cases-00.txt (Work in Progress),
July 2005.
[8] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004.
[9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[10] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 3546, June 2003.
[11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
Alexander & Rutledge Expires April 26, 2006 [Page 19]
Internet-Draft Congestion Status Precondition October 2005
[12] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[14] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, September 2002.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
Authors' Addresses
Corey W. Alexander (editor)
Nortel
MS 08704A30
2370 Performance Drive
Richardson, Texas 75082
US
Phone: +1 972 684-8320
Email: coreya@nortel.com
John Rutledge
Nortel
MS 08704A30
2370 Performance Drive
Richardson, Texas 75082
US
Phone: +1 972 684-7528
Email: jrutledg@nortel.com
Alexander & Rutledge Expires April 26, 2006 [Page 20]
Internet-Draft Congestion Status Precondition October 2005
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Alexander & Rutledge Expires April 26, 2006 [Page 21]
