Internet DRAFT - draft-penno-message-flows
draft-penno-message-flows
Network Working Group R. Penno
Internet Draft Juniper Networks
Expires: November 2006 D. Malas
Level 3
S. Khan
Sprint
A. Uzelac
Global Crossing
May 2, 2006
SPEERMINT Routing Architecture Message Flows
draft-penno-message-flows-02
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 November 2, 2006.
Abstract
This draft provides the message flows associated with the SPEERMINT
routing architecture. We show message flows in several peering
scenarios.
penno Expires November 2, 2006 [Page 1]
Internet-Draft SPEERMINT Message Flows May 2006
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 RFC-2119 [1].
Table of Contents
1. Introduction......................................... 3
2. Peering Message flows................................. 6
3. On-Demand Peering .................................... 8
3.1.1. Transport Layer Security....................... 8
3.1.2. Proxy Authentication: Subscribe/Notify.......... 10
3.1.3. Proxy Authentication: Surrogate Registration..... 11
4. Static Peering...................................... 13
4.1.1. IPSec..................................... 13
4.1.2. Co-Location................................ 13
5. Media Relay ........................................ 14
6. Considerations on Private IP addresses.................. 16
7. Considerations on Media Flows.......................... 17
7.1. Decomposition................................... 17
7.2. QoS........................................... 17
8. Considerations on Multilateral Peering.................. 18
9. SIP Priority and SPEERMINT QoS......................... 18
9.1. Problem Statement ............................... 19
9.2. Packet Recognition and Marking..................... 19
9.2.1. Peering Classes of Service.................... 20
9.2.2. Network Address Translation................... 20
9.3. Accounting..................................... 20
9.4. Trust......................................... 20
10. SIP Policy Enforcement and Definition.................. 20
10.1. Local SIP Policy ............................... 21
10.2. Remote SIP Policy............................... 21
10.3. SIP Proceed Policy.............................. 21
11. Peering Domain Information Exchange.................... 23
11.1. Domain Routes.................................. 23
11.2. Authentication Credentials....................... 23
12. Security Considerations.............................. 24
13. IANA Considerations................................. 24
14. Conclusions........................................ 24
15. Acknowledgments.................................... 24
References............................................ 25
15.1. Normative References............................ 25
15.2. Informative References .......................... 25
Author's Addresses..................................... 26
Intellectual Property Statement .......................... 26
penno Expires November 2, 2006 [Page 2]
Internet-Draft SPEERMINT Message Flows May 2006
Disclaimer of Validity.................................. 27
Copyright Statement.................................... 27
Acknowledgment ........................................ 27
1. Introduction
This document shows the message flows associated with the most
relevant SPEERMINT routing architecture peering scenarios. Most of
the messages diagrams were based on previous work done by the SIP and
SIPPING working groups.
The document focuses on the messages exchanged for the purpose of
Layer 5 peering [7] between two domains. Messages exchanged for the
purposed of setting up SIP session within a domain are considered out
of scope and were already defined in other working groups.
The draft separates the Layer 5 peering scenarios in two major
peering scenarios.
o On-demand: In this scenario the SIP proxies in domains A and B
establish a peering relationship driven by the necessity to
deliver a SIP message to another domain. This is sometimes
referred as the email model.
o Static: In this scenario the peering relationship between proxies
A and B is statically provisioned independent of the establishment
of any SIP session between users in different domains.
Normally, media for a given SIP session follows a different path,
traversing a different device (most commonly a router) when crossing
peering domains. Alternatively, media for a given session can be
directed to traverse the same device used for Layer 5 peering, i.e.,
the same device that handles signaling when crossing domains. This
gives rises to two different models:
o Decomposed: In this model SIP proxies perform Layer 5 peering and
media is sent directly between the UAs involved in the session.
Signaling and media follow different paths.
o Collapsed: In this model the device that performs Layer 5 peering
also processes the associated media when crossing domains. In the
light of SPEERMINT these devices may need to process media mainly
when peering involves SIP entities in private address spaces. This
function is usually referred to as media relay and is usually
performed by a B2BUA or SBC (Session Border Controller). See [6]
for a complete discussion of SBC functions.
penno Expires November 2, 2006 [Page 3]
Internet-Draft SPEERMINT Message Flows May 2006
The decomposed or basic peering model picture is shown below. It is
worth mentioning that Proxy 1 and 2 can be separated by any number of
layer 3 hops. We will refer to this picture throughout this document.
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | DNS | . . | DNS | .
. | 1 | . . | 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. | . . | .
. | . . | .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |--------------| Proxy | .
. | 1 | . . | 2 | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . Media . | | .
. | UA 1 |<========================================>| UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
Figure 1 Basic Peering Picture.
The collapsed model is shown below:
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | DNS | . . | DNS | .
. | 1 | . . | 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. | . . | .
penno Expires November 2, 2006 [Page 4]
Internet-Draft SPEERMINT Message Flows May 2006
. | . . | .
. +-------+ . . +-------+ .
. | B2BUA | . . | B2BUA | .
. | & |--------------| & | .
. | other |**************| other |\ .
. /| funct | . . | funct | \ .
. / +-------+ . . +-------+* \ signaling .
. / * . . * \ .
. / * . . * \ .
. / * . . * \ .
. / * media . . * \ .
. / * . . * \ .
. / * . . * \ .
. / * . . * \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | UA 1 | . . | UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
Figure 2 Collapsed Peering Picture.
In a decomposed model, the signaling function (SF) and the media
function (MF) are implemented in separate entities. A B2BUA is
generally on the SIP path in the SF. The vertical control protocol
between the SF and MF is out of the scope of SPEERMINT. The
decomposed model is shown below:
............................ ..............................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | DNS | . . | DNS | .
. | 1 | . . | 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. | . . | .
. | . . | .
. +-------+ . . +-------+ .
. /| B2BUA |--------------| B2BUA |\ .
. / +-------+ +-------+ \ .
. / +-------+ +-------+ \ .
. / | MF |**************| MF | \ .
. / +-------+ . . +-------+* \signaling .
. / * . . * \ .
. / * . . * \ .
penno Expires November 2, 2006 [Page 5]
Internet-Draft SPEERMINT Message Flows May 2006
. / * . . * \ .
. / * media . . * \ .
. / * . . * \ .
. / * . . * \ .
. / * . . * \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . . | | .
. | UA 1 | . . | UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
Figure 3 Collapsed Peering Picture.
2. Peering Message flows
We first depict what we call the basic message flow. The various
scenarios differ mostly of how and when peering is implemented. As
mentioned earlier peering can be establish following the arrival of a
message at a border proxy or statically following an agreement
between both domains.
penno Expires November 2, 2006 [Page 6]
Internet-Draft SPEERMINT Message Flows May 2006
Alice Proxy 1 DNS Proxy 2 Bob
| | | | |
| | | | |
| | Peering | |
| | Phase | |
| | [Static] | |
| |<------------------>| |
| INVITE | | | |
|------->| | | |
| 100 | | | |
|<-------| | | |
| | NAPTR | | |
| | Query | | |
| |--------->| | |
| | NAPTR | | |
| | Reply | | |
| |"SIPS+D2T"| | |
| |<---------| | |
| | SRV | | |
| | Query | | |
| |--------->| | |
| | SRV | | |
| | Reply | | |
| |<---------| | |
| | | |
| | Peering | |
| | Phase | |
| | [On-Demand] | |
| |<------------------>| |
| | | |
| | INVITE | |
| |------------------->| INVITE |
| | 100 |---------->|
| |<-------------------| |
| | | 180 |
| | 180 |<----------|
| 180 |<-------------------| |
|<-------| | 200 |
| | 200 |<----------|
| 200 |<-------------------| |
|<-------| | |
| ACK | | |
|------->| ACK | |
| |------------------->| ACK |
| | |---------->|
| Both Way RTP Media |
|<=======================================>|
penno Expires November 2, 2006 [Page 7]
Internet-Draft SPEERMINT Message Flows May 2006
| | | BYE |
| | BYE |<----------|
| BYE |<-------------------| |
|<-------| | |
| 200 | | |
|------->| 200 | |
| |------------------->| 200 |
| | |---------->|
| | | |
In the collapsed model, media would follow the path shown below. All
other signaling call flows remain the same, except a B2BUA is used
instead of a proxy.
Alice B2BUA 1 DNS B2BUA 2 Bob
| | | | |
| | | | |
| Both Way RTP Media |
|<======>|<==================>|<==========>|
| | | BYE |
The following sections show the message flows in several different
scenarios broken in two categories, on-demand and static.
3. On-Demand Peering
In the on demand peering scenario, the relationship between proxies
in domains A and B is driven by the arrival of a SIP message at proxy
A directed to a user in domain B (or vice-versa).
3.1.1. Transport Layer Security
In this scenario, trust between domains A and B is implied by the TLS
connection. The TLS connection is only established as a result of the
first session between domains A and B.
penno Expires November 2, 2006 [Page 8]
Internet-Draft SPEERMINT Message Flows May 2006
Alice Proxy 1 DNS Proxy 2 Bob
| | | | |
| | | | |
| INVITE | | | |
|------->| | | |
| 100 | | | |
|<-------| | | |
| | NAPTR | | |
| | Query | | |
| |--------->| | |
| | NAPTR | | |
| | Reply | | |
| |"SIPS+D2T"| | |
| |<---------| | |
| | SRV | | |
| | Query | | |
| |--------->| | |
| | SRV | | |
| | Reply | | |
| |<---------| | |
| | | |
| | Peering | |
| | [TLS Connection] | |
| |<------------------>| |
| | | |
| | INVITE | |
| |------------------->| INVITE |
| | 100 |---------->|
| |<-------------------| |
| | | 180 |
| | 180 |<----------|
| 180 |<-------------------| |
|<-------| | 200 |
| | 200 |<----------|
| 200 |<-------------------| |
|<-------| | |
| ACK | | |
|------->| ACK | |
| |------------------->| ACK |
| | |---------->|
| Both Way RTP Media |
|<=======================================>|
| | | BYE |
| | BYE |<----------|
| BYE |<-------------------| |
|<-------| | |
| 200 | | |
penno Expires November 2, 2006 [Page 9]
Internet-Draft SPEERMINT Message Flows May 2006
|------->| 200 | |
| |------------------->| 200 |
| | |---------->|
| | | |
TBD: DNS exchange could present proxy 1 with a set of peering
policies that need to be met for the peering with proxy 2 two
succeed.
3.1.2. Proxy Authentication: Subscribe/Notify
In the following example message flow, the authentication credentials
exchange method may take place before any INVITE is sent by ALICE.
The P2Key is sent by Proxy 2's NOTIFY and is included in the
"PeerAuthEventPkg". The P2Key may be stored on Proxy 1 for the
duration of the subscription. When the subscription expires, the
P2Key becomes invalid. At any time before the subscription expires,
the P2Key MAY be updated or refreshed as described in [8]. The
message flow and authentication exchange may occur in either
direction, but for simplicity reasons is only shown unilaterally.
The method is the same as indicated in section 3.2.
penno Expires November 2, 2006 [Page 10]
Internet-Draft SPEERMINT Message Flows May 2006
ALICE Proxy 1(P1) Proxy 2(P2) Bob
| | | |
| INVITE | | |
|--------------->| | |
| 100 Trying | | |
|<---------------| | |
| |Subscribe w/PeerAuthEventPkg | |
| |---------------------------->| |
| | 401 Unauthorized | |
| |<----------------------------| |
| |Subscribe w/Auth | |
| |---------------------------->| |
| | 202 Accepted | |
| |<----------------------------| |
| | Notify w/P2Key | |
| |<----------------------------| |
| | 200 OK | |
| |---------------------------->| |
| | INVITE | |
| |---------------------------->| |
| | 401 Unauthorized | |
| |<----------------------------| |
| | INVITE w/P2Key | |
| |---------------------------->| |
| | 100 Trying |INVITE |
| |<----------------------------|-----------> |
| | |180 Ringing |
| | 180 Ringing |<----------- |
| 180 Ringing|<----------------------------| |
|<---------------| |200 OK |
| | 200 OK |<----------- |
| 200 OK |<----------------------------| |
|<---------------| | |
| ACK | | |
|--------------->|ACK | |
| |---------------------------->|ACK |
| | |-----------> |
3.1.3. Proxy Authentication: Surrogate Registration
In this optional scenario we are assuming a new type Proxy
authentication method exists that allows mutual authentication
between two proxies. This authentication can be termed as the
"Surrogate Authentication". Generally, a proxy cannot register with
another proxy because in between two proxies there is not child-
penno Expires November 2, 2006 [Page 11]
Internet-Draft SPEERMINT Message Flows May 2006
parent relationship. However, an originating proxy can register with
another proxy on behalf of a User Agent (UA).
ALICE Proxy 1(P1) Proxy 2(P2) Bob
| | | |
| INVITE | | |
|--------------->| | |
| 100 Trying | | |
|<---------------| | |
| |REGISTER | |
| |------------------->| |
| | 401 Unauthorized | |
| |<-------------------| |
| |REGISTER w/Auth | |
| |------------------->| |
| | 100 Trying | |
| |<-------------------| |
| | 200 OK w/P2Key | |
| |<-------------------| |
| | REGISTER | |
| |<-------------------| |
| | 401 Unauthorized | |
| |------------------->| |
| | REGISTER w/Auth| |
| |<-------------------| |
| | 100 Trying | |
| |------------------->| |
| | 200 OK w/P1Key | |
| |------------------->| |
| | INVITE w/P2Key | |
| |------------------->| |
| | 100 Trying |INVITE |
| |<-------------------|-----------> |
| | |180 Ringing |
| | 180 Ringing |<----------- |
| 180 Ringing|<-------------------| |
|<---------------| |200 OK |
| | 200 OK |<----------- |
| 200 OK |<-------------------| |
|<---------------| | |
| ACK | | |
|--------------->|ACK | |
| |------------------->|ACK |
| | |-----------> |
penno Expires November 2, 2006 [Page 12]
Internet-Draft SPEERMINT Message Flows May 2006
4. Static Peering
In the static peering scenario the relationship between proxies A and
B is not driven by a SIP session, but before hand through manual
provisioning.
4.1.1. IPSec
In this model an IPSec connection between proxies A and B is
provisioned following an agreement between the two domains.
Alice Proxy 1 DNS Proxy 2 Bob
| | | | |
| | | |
| | [Peering] | |
| | IPSec Connection | |
| |<------------------>| |
| | | | |
\ / \ / \
/ \ / \ /
| | | | |
| INVITE | | | |
|------->| | | |
| 100 | | | |
|<-------| | | |
\ / \ / \
/ \ / \ /
| | BYE |<----------|
| BYE |<-------------------| |
|<-------| | |
| 200 | | |
4.1.2. Co-Location
In this scenario the two proxies are co-located in a physical secure
location and/or are member of a segregated network. In this case
messages between Proxy 1 and Proxy 2 would be sent as clear text.
penno Expires November 2, 2006 [Page 13]
Internet-Draft SPEERMINT Message Flows May 2006
Alice Proxy 1 DNS Proxy 2 Bob
| | | | |
| | | |
| | [Peering] | |
| | Co-Location | |
| |<------------------>| |
| | | | |
\ / \ / \
/ \ / \ /
| | | | |
| INVITE | | | |
|------->| | | |
| 100 | | | |
|<-------| | | |
\ / \ / \
/ \ / \ /
| | BYE |<----------|
| BYE |<-------------------| |
|<-------| | |
| 200 | | |
5. Media Relay
In the event that a calling and/or called entity are part of a
private network and the NAT/FW at the CPE is VoIP unaware or the
client uses to NAT traversal method, the SIP Proxy must find a way to
modify the private addresses that remain in the signaling payload (in
addition to threading media through the NAT/FW). This modifying
process is sometimes referred to as Far-end NAT Traversal (FE-NTRV).
The core of the FE-NTRV process is media relaying. The Signaling
entity relays media between the two endpoints as a result of the
repairing process and to guarantee NAT/FW traversal (symmetric RTP).
It is important to understand that media relay can be used
independent of NAT/FW as a way to direct media to a certain device
for processing. In the context of SPEERMINT media relay could be
used to enable the collapsed model and/or perform FE-NTRV.
penno Expires November 2, 2006 [Page 14]
Internet-Draft SPEERMINT Message Flows May 2006
ALICE NAT/FW Media Relay Bob
10.10.1.2 Signaling:128.16.5.10 192.32.6.2
Media:168.12.1.8
| | | |
| INVITE | | |
|------------------>| INVITE | |
|s:10.10.1.2:9082 |------------------->| INVITE |
|d:128.16.5.10:5060 |s:140.1.1.1:23040 |------------------>|
|c= 10.10.1.2 |d:128.16.5.10:5060 |s:128.16.5.10:5060 |
|m= 11032 |c= 10.10.1.2 |d:192.32.6.2:5060 |
| |m= audio 11032 |c= 168.12.1.8 |
| | |m= audio 3600 |
| | | |
|
v
+---------------------------------------------------------------------+
| Media Relay creates of a pair of media relay ports. The first port, |
| 3600, is for receiving media from the called party and the 2nd |
| port, 7600, is for receiving media from the calling party. As we do |
| not know what the transport address of the calling party will be |
| (post NAPT), any media received from the called party must be |
| dropped. |
+---------------------------------------------------------------------+
| | | 200 OK |
| | 200 OK |<------------------|
| 200 OK |<-------------------|s:192.32.6.2:5060 |
|<------------------|s:128.16.5.10:5060 |d:128.16.5.10:5060 |
|s:128.16.5.10:5060 |d:140.1.1.1:23040 |c= 192.32.6.2 |
|d:10.10.1.2:9082 |c= 168.12.1.8 |m= audio 9080 |
|c= 168.12.1.8 |m= audio 7600 | |
|m= audio 7600 | | |
| | | |
| | | |
|
V
+----------------------------+
| Media Relay updates remote |
| dest. as 192.32.6.2:9080 |
+----------------------------+
| | | |
| ACK (...) | | |
|------------------>| | |
| | | Media |
| | X<==================|
penno Expires November 2, 2006 [Page 15]
Internet-Draft SPEERMINT Message Flows May 2006
| | |s:168.12.1.8:3600 |
| | |d:192.32.6.2:9080 |
| | | |
| | v |
Discarded
| Media | |
|=======================================>|==================>|
|s:10.10.1.2:11032 |s:140.1.1.1:16220 |s:168.12.1.8:3600 |
|d:168.12.1.8:7600 |d:168.12.1.8:7600 |d:192.32.6.2:9080 |
| | | |
| | v |
+---------------------------+
| Update remote destination |
+---------------------------+
| | | |
| Media | |
|<=======================================|<==================|
|s:168.12.1.8:7600 |s:168.12.1.8:7600 |s:192.32.6.2:9080 |
|d:10.10.1.2:11032 |d:140.1.1.1:16220 |d:168.12.1.8:3600 |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
6. Considerations on Private IP addresses
In Layer 5 peering scenarios, it does not really matter if the
peering fabric is public or private. What is relevant is if one of
the SIP devices participating in the session is in a public address
space and the other in a private.
In this case some observations should be made:
o A SIP device in a private address space can only communicate with
a device in a public address space if a NAT binding from private
to public address is provided.
o If a SIP device is in a private address space behind legacy NAT
device and does implement a NAT traversal method [8], media relay
might be needed for the successful establishment of the session.
Media relay is most commonly implemented by a B2BUA or SBC. A
legacy Nat is one that does not implement a SIP Application Level
Gateway (ALG).[4]
penno Expires November 2, 2006 [Page 16]
Internet-Draft SPEERMINT Message Flows May 2006
7. Considerations on Media Flows
7.1. Decomposition
The scenarios in the previous sections show media flowing between the
endpoints involved in the SIP session, but it is important to
understand that the domains involved in peering might not carry the
media associated with such sessions.
Media associated with the sessions established across the peering
interface could be carried by a traditional ISP. The picture below
depicts such scenario.
+---------+ _________
/--->| VSP |<-----\
/ | | \
| +---------+ |
Signaling | | Signaling
(peering) | | (peering)
| |
+------------+ | | +------------+
| |<-/ +-----------+_ \->| |
| | | | | |
| Domain A |>------->| ISP |>-------->| Domain B |
| |<-------<|___________|<--------<| |
|____________| Media | | Media |____________|
+------------+ +-----------+ +------------+
7.2. QoS
Media flows for real time communication usually need strict
scheduling guarantees in order to not degrade the service. The
problem of QoS within an independent administratively domain and
across domains is quite different.
In the case L5 peering several issues arise around QoS for media
flows, especially in the case of on-demand peering. Some of these
issues are listed below.
o How to reconcile general QoS parameters used in domain A across
the peering interface with those announced by domain B's peering
policy?
penno Expires November 2, 2006 [Page 17]
Internet-Draft SPEERMINT Message Flows May 2006
o How domain B can identify media flows crossing the peering
interface coming from domain A (and vice-versa) in order to
provide the agreed upon QoS treatment? We could potentially be
talking about hundreds of call (and consequently new media flows)
per second.
o Moreover, in a decomposed scenario, how the SIP Proxy can let the
router know the identity of such media flows and the QoS
parameters associated with it? This problem was discussed under
the TISPAN umbrella and NGN networks [6].
o Alternatively or in conjunction with dynamic identification there
is the issue of trust. Possibly domain B could trust domain A to
mark all media packets appropriately. Domain B would honor such
markings and give the appropriate treatment announced on its
peering policy
8. Considerations on Multilateral Peering
Some of the difficulties discussed in previous sections would be
aggravated in the case of multilateral on-demand peering where
potentially more than on VSP could carry signaling (and possibly
media) to reach a specific endpoint.
How peering policies could be compared to find out the best one for a
specific case? In the case of routing protocols a combination of
metrics, route filtering and others techniques provide a solution.
+---------+
| |
/ | Domain |\
/ | C | \
/ | | \
/ +---------+ \
/ \
+--------+ / +---------+ \ +--------+ +-----+
| |---/ | | \----| | | |
| Domain | | Domain | | Domain | | UA |
| A |-----------| B |-----------| D |-------| |
| | | | | | +-----+
+--------+ +---------+ +--------+
9. SIP Priority and SPEERMINT QoS
As discussed in section 7.2, there are various QoS aspects that need
to be taken into account in the context of SPEERMINT.
penno Expires November 2, 2006 [Page 18]
Internet-Draft SPEERMINT Message Flows May 2006
The next sections discuss those aspects by first going laying out
some groundwork and then going through scenarios.
9.1. Problem Statement
When SIP signaling and media packets from UA 1 arrive at peering
point destined to UA 2, the Layer 5 peering devices need to make sure
those packets receive the proper treatment when crossing the peering
fabric into another domain. Proper treatment involves three aspects:
Packet recognition and marking, accounting and trust.
9.2. Packet Recognition and Marking
If the layer 5 peering devices (referred as SIP Proxies) are going to
mark signaling and media packets, they need to first be able to
recognize them. Recognizing and marking SIP signaling is not
problematic since we assume the Layer 5 peering devices perform SIP
proxy functions. It leaves the media packets.
If the SIP Proxy does not inspect the SDP payload in SIP messages to
learn how to identify media packets, the only solution is to trust
that the endpoints or an upstream proxy have already done it (see
section 8.3).
On the other hand, if the SIP Proxy performs SDP inspection, it will
be able to recognize media packets based on the contents of the c and
m lines. It is important to notice that there is an implicit
assumption of what will be negotiated, and also that this proxy stays
in the signaling call flow for the duration of the call - and
therefore be aware of mid-call events.
Now we come to the problem of which device will mark the packets. In
a decomposed scenario, the SIP proxy needs to let the router know how
to identify media packets and which marking to use. One possible
solution is the use of a Gate Control Protocol [6].
In a collapsed scenario the problem of identifying and marking
packets is less severe.
penno Expires November 2, 2006 [Page 19]
Internet-Draft SPEERMINT Message Flows May 2006
9.2.1. Peering Classes of Service
In the simplest the case the peering fabric will have a set of
classes of service that serve as a translation table from one domain
to another. So, a domain A only needs to know how to map the classes
of service used internally to the ones used in the peering point (and
vice-versa).
9.2.2. Network Address Translation
The use of NAT media makes packet recognition problem more severe. As
discussed in section 6, in certain scenarios the identification of
the media flows require special processing.
9.3. Accounting
Accounting refers to the tracking consumption of network resources by
sessions. In order to accomplish inter-domain accounting, it is
required to know the exchanged policies, resources available and
reachability. Within the information gathered, it is important to
know the identity of the session, the nature of the service
delivered, when the service began, and when it ended.
9.4. Trust
If Proxy 1 trusts that its users will mark packets correctly, the
issue of packet recognition and marking can be mitigated. Of course
that does not imply that Proxy 2 trusts Domain 1 to mark packets
correctly. That's where a QoS policy exchange comes into play.
10. SIP Policy Enforcement and Definition
Within the following description, there is an assumption that the SIP
Proxy will know via policy exchange, variables that will weigh
potentially in routing decisions from Proxy A to Proxy B, (e.g.
defined relationship, trust established, etc).
In the inter-domain exchange of SIP signaled real-time sessions, the
SIP proxy will be the policy decision point that enforces exchanged
session policies. In this signaling plane enforcement model, all
bearer traffic will receive the same level of QOS (e.g. EF). Real-
time traffic (voice, video, etc) share the same sensitivity to
latency, jitter, and packet loss. Therefore any direct inter-domain
QoS mapping of service levels is not needed. Should one type of
traffic (Video) have more significance than another (voice) then the
SIP proxy will enforce that policy, possible preempting existing
sessions if required.
penno Expires November 2, 2006 [Page 20]
Internet-Draft SPEERMINT Message Flows May 2006
In both the collapsed and decomposed inter-domain call models, the
SIP proxies of both the originating and terminating domains have the
authority to permit, deny, preempt and throttle sessions. Inspecting
and classifying at the SIP layer brings an added differentiation
superseding Layer 3 policies.
10.1. Local SIP Policy
Local SIP Policy is defined as that which has local significance, or
not appropriate to exchange beyond administrative domains. Examples
of local policies would be preferential treatment of sessions based
on hierarchical subscriber groupings ("gold level" subscribers), path
selection based on time of day, or presence.
10.2. Remote SIP Policy
Remote SIP Policy is defined as policies that are learned via
exchange mechanism with peer in remote administrative domain.
Examples of a remote policy would be the codec to use, or number of
sessions permitted.
10.3. SIP Proceed Policy
The Proceed policy is used to determine if a session attempt should
be permitted to continue or not. The Proceed policy is constructed
from a merging of local and remote policies learned via exchange
mechanism. Permitting of a session to proceed or not can be done by
any SIP proxy involved in inter-domain signaling of the session.
The need for a scalable/fast implementation that will track current
state information in real-time can be achieved by RADIUS. A real-
time and historical session activity database will have a full
history of all active sessions. When a Session attempt is made from
a UA, it will be accounted for on session accounting element of the
SIP Proxy. The accounting element(s) can maintain data on whatever
criteria pertinent to track (codec, domain, timestamps etc...) When
new session attempt is made, an accounting look-up is done and a
search on whatever criteria of interest is done to determine if
session signaling can proceed. See the Policy Decision Point (PDP) in
below call flow.
penno Expires November 2, 2006 [Page 21]
Internet-Draft SPEERMINT Message Flows May 2006
Call Flow Examples:
Alice Proxy 1 Radius Proxy 2 Bob
| | | | |
|INVITE | | | |
|------->| | | |
| 100 | | | |
|<-------| Session | | |
| | Attempt | | |
| |---------->| | |
| | Current | | |
| | Peer Stats| | |
| |<----------| | |
| (PDP) | | |
| | INVITE | | |
| |--------------------->| INVITE |
| | 100 | |--------->|
| |<---------------------|180 |
| | 180 | |<---------|
| 180 |<---------------------| |
|<-------| | |200 |
| | 200 | |<---------|
| 200 |<---------------------| |
|<-------| | | |
| ACK | | | |
|------->| ACK | | |
| |--------------------->|ACK |
| | | |--------->|
| | | | |
SIP proxies talk to a list of radius servers for accounting purposes.
The radius servers should be on a local network to the proxy.
Prior to Proxy 1 sending INVITE to Proxy 2, a determination will be
made based on the exchanged policies if the attempt at session
establishment should be permitted.
TBD: An orthogonal point - The T-domain proxy in this instance is
from the perspective of the O-domain proxy. It may not be the
ultimate T-domain there may not be transparency through the next-hop
to the T-domain where the T-UA resides.**
penno Expires November 2, 2006 [Page 22]
Internet-Draft SPEERMINT Message Flows May 2006
11. Peering Domain Information Exchange
11.1. Domain Routes
In some cases, it may be required to exchange specific domain route
information between peers. The following describes a method for a
relationship between proxies in domains A and B to exchange domain
routes using a SIP peering route event package. This event package
will provide routing information for the peering proxy server to
update its routing table with new peering routes. This method
utilizes a SUBSCRIBE method, and routes may be updated through expiry
timers and subscription refreshes as defined in [8].
Proxy 1 Proxy 2
| |
|Subscribe w/PeerRteEventPkg |
|---------------------------->|
| 401 Unauthorized |
|<----------------------------|
|Subscribe w/Auth |
|---------------------------->|
| 202 Accepted |
|<----------------------------|
| Notify |
|<----------------------------|
| 200 OK |
|---------------------------->|
11.2. Authentication Credentials
In some cases, authorization credentials for authentication methods
such as HTTP digest may want to be exchanged and utilized by domain
proxies for authenticating new message requests from subscribers
intended for a UA in another domain. The following describes a
method for a relationship between proxies in domains A and B to
exchange a, potential, undefined peering authentication event
package. This method utilizes a SUBSCRIBE method similar to the
method described in section 3.1. An example, including a UA INVITE
message flow is included in section 4.1.2.
penno Expires November 2, 2006 [Page 23]
Internet-Draft SPEERMINT Message Flows May 2006
Proxy 1 Proxy 2
| |
|Subscribe w/PeerAuthEventPkg |
|---------------------------->|
| 401 Unauthorized |
|<----------------------------|
|Subscribe w/Auth |
|---------------------------->|
| 202 Accepted |
|<----------------------------|
| Notify |
|<----------------------------|
| 200 OK |
|---------------------------->|
12. Security Considerations
The level of security required during the establishment and
maintenance of a SIP peering relationship between to proxies can vary
greatly. In general all security considerations related to the SIP
protocol are also applicable in a peering relationship.
If the two proxies communicate over an insecure network, and
consequently are subject to attacks, the use of a TLS or IPSec would
be advisable.
If there is physical security and the proxies are co-located, or the
proxies are situated in a segregated network (such as VPN), one could
argue that basic filtering based on IP address is enough.
13. IANA Considerations
There are no IANA considerations at this point
14. Conclusions
The purpose of this draft is to show SPEERMINT message flows as
specified in charter but also to raise awareness through questions
and detailed considerations of several issues the WG might have to
deal in different peering scenarios.
15. Acknowledgments
TBD
penno Expires November 2, 2006 [Page 24]
Internet-Draft SPEERMINT Message Flows May 2006
References
15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[5] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, December 2003.
[6] ETSI TS 102 333: " Telecommunications and Internet converged
Services and Protocols for Advanced Networking (TISPAN); Gate
control protocol".
[7] Babiarz, J., "Configuration Guidelines for DiffServ Service
Classes", draft-ietf-tsvwg-diffserv-service-classes-02 (work in
progress), February,2006.
[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
15.2. Informative References
[9] Camarillo, G., Penfield, R., Hawrylyshen, A., "Requirements
from SIP (Session Initiation Protocol) Session Border
Controller Deployments", Internet Draft, draft-camarillo-
sipping-sbc-funcs-03
[10] Meyer, D., "SPEERMINT Requirements and Terminology", Internet
Draft, draft-ietf-speermint-reqs-and-terminology-01
[11] Boulton, C., Rosenberg, J., Camarillo, G., "Best Current
Practices for NAT Traversal for SIP", Internet Draft, draft-
ietf-sipping-nat-scenarios-04
penno Expires November 2, 2006 [Page 25]
Internet-Draft SPEERMINT Message Flows May 2006
Author's Addresses
Daryl Malas
Level 3 Communications LLC
1025 Eldorado Blvd.
Broomfield, CO 80021
USA
EMail: daryl.malas@level3.com
Sohel Khan, Ph.D.
Technology Strategist
Sprint
6220 Sprint Parkway
Overland Park, KS 66251
U.S.A
Email: Sohel.Q.Khan@sprint.com
Reinaldo Penno
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA
USA
Email: rpenno@juniper.net
Adam Uzelac
Global Crossing
1120 Pittsford Victor Road
PITTSFORD, NY 14534
USA
Email: adam.uzelac@globalcrossing.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
penno Expires November 2, 2006 [Page 26]
Internet-Draft SPEERMINT Message Flows May 2006
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 (2006).
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.
penno Expires November 2, 2006 [Page 27]
