this appendix will only discuss the reservations from Alice to Bob
(one direction) and from Carol to Dave (one direction). An
interactive voice service will require two one-way reservations that
end in each UA. This gives the appearance of a two-way reservation,
when indeed it is not.
Alice -----R1----R2----R3----R4------ Bob
| \ / \ / \ / |
| \/ \/ \/ |
| /\ /\ /\ |
| / \ / \ / \ |
Carol -----R5----R6----R7----R8------ Dave
Figure 5: Complex Routing and Reservation Topology
The PATH message from Alice to Bob (establishing the route for the
RESV message) will be through routers:
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
The RESV message (and therefore the reservation of resources) from
Bob to Alice will be through routers:
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
The PATH message from Carol to Dave (establishing the route for the
RESV message) will be through routers:
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
The RESV message (and therefore the reservation of resources) from
Dave to Carol will be through routers:
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
The reservations from Alice to Bob traverse a common router link:
between R3 and R2 and thus a common interface at R2. Here is where
there will be congestion in this example, on the link between R2 and
R3. Since the flow of data (in this case voice media packets)
travels the direction of the PATH message, and RSVP establishes
reservation of resources at the egress interface of a router, the
interface in Figure 6 shows that Int7 will be what first knows about
a congestion condition.
Alice Bob
\ /
\ /
+--------+ +--------+
| | | |
| R2 | | R3 |
| Int7-------Int5 |
| | | |
+--------+ +--------+
/ \
/ \
Carol Dave
Figure 6: Reduced Reservation Topology
Figure 6 illustrates how the messaging between the UAs and the RSVP
messages between the relevant routers can be shown to understand the
binding that was established in [RFC3312] (more suitably titled "SIP
Preconditions for QoS" from this document’s point of view).
We will assume all devices have powered up and received whatever
registration or remote policy downloads were necessary for proper
operation. The routing protocol of choice has performed its routing
table update throughout this part of the network. Now we are left to
focus only on end-to-end communications and how that affects the
infrastructure between endpoints.
The next diagram (Figure 7) (nearly identical to Figure 1 from
[RFC3312]) shows the minimum SIP messaging (at layer 7) between Alice
and Bob for a good-quality voice call. The SIP messages are numbered
to identify special qualities of each. During the SIP signaling,
RSVP will be initiated. That messaging will also be discussed below.
UA Alice UA Bob
| |
| |
|-------------(1) INVITE SDP1--------------->|
| | Note 1
|<------(2) 183 Session Progress SDP2--------| |
***|********************************************|***<-+
* |----------------(3) PRACK------------------>| *
* | | * Where
* |<-----------(4) 200 OK (PRACK)--------------| * RSVP
* | | * is
* | | * signaled
***|********************************************|***
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| RTP (within the reservation) |
|<==========================================>|
| |
Figure 7: SIP Reservation Establishment Using Preconditions
The session initiation starts with Alice wanting to communicate with
Bob. Alice decides on an IEPS precedence level for their call (the
default is the "routine" level, which is for normal everyday calls,
but a priority level has to be chosen for each call). Alice puts
into her UA Bob’s address and precedence level and (effectively) hits
the send button. This is reflected in SIP with an INVITE Method
Request message [M1]. Below is what SIP folks call a well-formed SIP
message (meaning it has all the headers that are mandatory to
function properly). We will pick on the US Marine Corps (USMC) for
the addressing of this message exchange.
[M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory]
INVITE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
Require: 100rel, preconditions, resource-priority
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 191
v=0
o=alice 2890844526 2890844526 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
From the INVITE above, Alice is inviting Bob to a session. The upper
half of the lines (above the line "v=0") is SIP headers and header
values, and the lower half is Session Description Protocol (SDP)
lines. SIP headers (after the first line, called the Status line)
are not mandated in any particular order, with one exception: the Via
header. It is a SIP hop (through a SIP Proxy) route path that has a
new Via header line added by each SIP element this message traverses
towards the destination UA. This is similar in function to an RSVP
PATH message (building a reverse path back to the originator of the
message). At any point in the message’s path, a SIP element knows
the path to the originator of the message. There will be no SIP
Proxies in this example, because for Preconditions, Proxies only make
more messages that look identical (with the exception of the Via and
Max-Forwards headers), and it is not worth the space here to
replicate what has been done in SIP RFCs already.
SIP headers that are used for Preconditions are as follows:
o Require header, which contains 3 option tags: "100rel" mandates a
reliable provisional response message to the conditions requesting
in this INVITE (knowing they are special), "preconditions"
mandates that preconditions are attempted, and "resource-priority"
mandates support for the Resource-Priority header. Each of these
option tags can be explicitly identified in a message failure
indication from the called UA to tell the calling UA exactly what
was not supported.
Provided that this INVITE message is received as acceptable, this
will result in the 183 "Session Progress" message from Bob’s UA, a
reliable confirmation that preconditions are required for this
call.
o Resource-Priority header, which denotes the domain namespace and
precedence level of the call on an end-to-end basis.
This completes SIP’s functions in session initiation. Preconditions
are requested, required, and signaled for in the SDP portion of the
message. SDP is carried in what’s called a SIP message body (much
like the text in an email message is carried). SDP has special
properties (see [RFC2327] for more on SDP, or the MMUSIC WG for
ongoing efforts regarding SDP). SDP lines are in a specific order
for parsing by end systems. Dialog-generating (or call-generating)
SDP message bodies all must have an "m=" line (or media description
line). Following the "m=" line are zero or more "a=" lines (or
Attribute lines). The "m=" line in Alice’s INVITE calls for a voice
session (this is where video is identified also) using one of 3
different codecs that Alice supports (0 = G.711, 4 = G.723, and 18 =
G.729) that Bob gets to choose from for this session. Bob can choose
any of the 3. The first a=rtpmap line is specific to the type of
codec these 3 are (PCMU). The next two "a=" lines are the only
identifiers that RSVP is to be used for this call. The second "a="
line:
a=curr:qos e2e none
identifies the "current" status of qos at Alice’s UA. Note:
everything in SDP is with respect to the sender of the SDP message
body (Alice will never tell Bob how his SDP is; she will only tell
Bob about her SDP).
"e2e" means that capacity assurance is required from Alice’s UA to
Bob’s UA; thus, a lack of available capacity assurance in either
direction will fail the call attempt.
"none" means there is no reservation at Alice’s UA (to Bob) at
this time.
The final "a=" line (a=des) identifies the "desired" level of qos:
a=des:qos mandatory e2e sendrecv
"mandatory" means this request for qos MUST be successful, or the
call fails.
"e2e" means RSVP is required from Alice’s UA to Bob’s UA.
"sendrecv" means the reservation is in both directions.
As discussed, RSVP does not reserve bandwidth in both directions, and
it is up to the endpoints to have 2 one-way reservations if that
particular application (here, voice) requires it. Voice between
Alice and Bob requires 2 one-way reservations. The UAs will be the
focal points for both reservations in both directions.
Message 2 is the 183 "Session Progress" message sent by Bob to Alice,
which indicates to Alice that Bob understands that preconditions are
required for this call.
[M2 - 183 "Session Progress"]
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9 ;received=10.1.3.33
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
RSeq: 813520
Resource-Priority: dsn.routine
Contact: <sip:bob@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 210
v=0
o=bob 2890844527 2890844527 IN IP4 usmc.example.mil
c=IN IP4 10.100.50.51
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
The only interesting header in the SIP portion of this message is the
RSeq header, which is the "Reliable Sequence" header. The value is
incremented for every Reliable message that’s sent in this call setup
(to make sure none are lost or to ignore duplicates).
Bob’s SDP indicates several "a=" line statuses and picks a codec for
the call. The codec picked is in the m=audio line (the "0" at the
end of this line means G.711 will be the codec).
The a=curr line gives Alice Bob’s status with regard to RSVP
(currently "none").
The a=des line also states the desire for mandatory qos e2e in both
directions.
The a=conf line is new. This line means Bob wants confirmation that
Alice has 2 one-way reservations before Bob’s UA proceeds with the
SIP session setup.
This is where "Note-1" applies in Figure 7. At the point that Bob’s
UA transmits this 183 message, Bob’s UA (the one that picked the
codec, so it knows the amount of bandwidth to reserve) transmits an
RSVP PATH message to Alice’s UA. This PATH message will take the
route previously discussed in Figure 5:
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
This is the path of the PATH message, and the reverse will be the
path of the reservation setup RESV message, or:
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
Immediately after Alice transmits the RESV message towards Bob, Alice
sends her own PATH message to initiate the other one-way reservation.
Bob, receiving that PATH message, will reply with a RESV.
All this is independent of SIP. However, during this time of
reservation establishment, a Provisional Acknowledgement (PRACK) [M3]
is sent from Alice to Bob to confirm the request for confirmation of
2 one-way reservations at Alice’s UA. This message is acknowledged
with a normal 200 OK message [M4]. This is shown in Figure 7.
As soon as the RSVP is successfully completed at Alice’s UA (knowing
that it was the last in the two-way cycle or reservation
establishment), at the SIP layer an UPDATE message [M5] is sent to
Bob’s UA to inform his UA that the current status of RSVP (or qos) is
"e2e" and "sendrecv".
[M5 - UPDATE to Bob that Alice has qos e2e and sendrecv]
UPDATE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 191
v=0
o=alice 2890844528 2890844528 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
This is shown by the matching table that can be built from the a=curr
line and a=des line. If the two lines match, then no further
signaling needs take place with regard to "qos". [M6] is the 200 OK
acknowledgement of this synchronization between the two UAs.
[M6 - 200 OK to the UPDATE from Bob indicating synchronization]
SIP/2.0 200 OK sip:bob@usmc.example.mil
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: < sip:alice@usmc.example.mil >
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 195
v=0
o=alice 2890844529 2890844529 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
At this point, the reservation is operational and both UAs know it.
Bob’s UA now rings, telling Bob the user that Alice is calling him.
([M7] is the SIP indication to Alice that this is taking place).
Nothing up until now has involved Bob the user. Bob picks up the
phone (generating [M10], from which Alice’s UA responds with the
final ACK), and RTP is now operating within the reservations between
the two UAs.
Now we get to Carol calling Dave. Figure 6 shows a common router
interface for the reservation between Alice to Bob, and one that will
also be the route for one of the reservations between Carol to Dave.
This interface will experience congestion in our example.
Carol is now calling Dave at a Resource-Priority level of
"Immediate", which is higher in priority than Alice to Bob’s
"routine". In this continuing example, Router 2’s Interface-7 is
congested and cannot accept any more RSVP traffic. Perhaps the
offered load is at interface capacity. Perhaps Interface-7 is
configured with a fixed amount of bandwidth it can allocate for RSVP
traffic, and it has reached its maximum without one of the
reservations going away through normal termination or forced
termination (preemption).
Interface-7 is not so full of offered load that it cannot transmit
signaling packets, such as Carol’s SIP messaging to set up a call to
Dave. This should be by design (that not all RSVP traffic can starve
an interface from signaling packets). Carol sends her own INVITE
with the following important characteristics:
[M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory]
This packet does *not* affect the reservations between Alice and Bob
(SIP and RSVP are at different layers, and all routers are passing
signaling packets without problems). Dave sends his M2:
[M2 - 183 "Session Progress"]
with the SDP chart of:
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
indicating he understands RSVP reservations are required e2e for this
call to be considered successful. Dave sends his PATH message. The
PATH message does *not* affect Alice’s reservation; it merely
establishes a path for the RESV reservation setup message to take.
To keep this example simple, the PATH message from Dave to Carol took
this route (which we make different from the route in the reverse
direction):
Dave -> R8 -> R7 -> R6 -> R5 -> Carol
causing the reservation to be this route:
Carol -> R5 -> R6 -> R7 -> R8 -> Dave
The Carol-to-Dave reservation above will not traverse any of the same
routers as the Alice-to-Bob reservation. When Carol transmits her
RESV message towards Dave, she immediately transmits her PATH message
to set up the complementary reservation.
The PATH message from Carol to Dave be through routers:
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
Thus, the RESV message will be through routers:
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
This RESV message will traverse the same routers, R3 and R2, as the
Alice-to-Bob reservation. This RESV message, when received at
Interface-7 of R2, will create a congestion situation such that R2
will need to make a decision on whether:
o to keep the Alice-to-Bob reservation and error the new RESV from
Dave, or
o to error the reservation from Alice to Bob in order to make room
for the Carol-to-Dave reservation.
Alice’s reservation was set up in SIP at the "routine" precedence
level. This will equate to a comparable RSVP priority number (RSVP
has 65,535 priority values, or 2*32 bits per [RFC3181]). Dave’s RESV
equates to a precedence value of "immediate", which is a higher
priority. Thus, R2 will preempt the reservation from Alice to Bob
and allow the reservation request from Dave to Carol. The proper
RSVP error is the ResvErr that indicates preemption. This message
travels downstream towards the originator of the RESV message (Bob).
This clears the reservation in all routers downstream of R2 (meaning
R3 and R4). Once Bob receives the ResvErr message indicating
preemption has occurred on this reservation, Bob’s UA transmits a SIP
preemption indication back towards Alice’s UA. This accomplishes two
things: first, it informs all SIP Servers that were in the session
setup path that wanted to remain "dialog stateful" per [RFC3261], and
second, it informs Alice’s UA that this was a purposeful termination,
and to play a preemption tone. The proper indication in SIP of this
termination due to preemption is a BYE Method message that includes a
Reason Header indicating why this occurred (in this case, "Reserved
Resources Preempted"). Here is the message from Bob to Alice that
terminates the call in SIP.
BYE sip:alice@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP swp34.usmc.example.mil
;branch=z9hG4bK776asegma
To: Alice <sip:alice@usmc.example.mil>
From: Bob <sip:bob@usmc.example.mil>;tag=192820774