Network Working Group R. Penno
Internet Draft Juniper Networks
Expires: April 2007 D. Malas
Level 3
P. Melampy
ACME packet
October 20, 2006
A Session Initiation Protocol (SIP) Event package for Peering
draft-penno-sipping-peering-package-01
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 March 20, 2007.
Abstract
This document defines a new SIP event package for the exchange of SIP
peering policies. It describes how SIP SUBSCRIBE/NOTIFY and PUBLISH
methods can be used by SIP Proxies engaged in peering to exchange
penno Expires April 20, 2007 [Page 1]
Internet-Draft Peering Policy Event Package October 2006
peering polices with minimal user or administrative intervention. It
also provides a description of the surrounding architecture in the
context of SPEERMINT.
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 Session-Dependent Policies.............................4
2.1. Overall Operation.........................................5
3. Event Package..................................................5
4. Use of PUBLISH Method..........................................6
5. Event Package Formal Definition................................6
5.1. Event Package Name........................................6
5.2. Event Package Parameters..................................6
5.3. SUBSCRIBE Bodies..........................................6
5.4. Subscription Duration.....................................6
5.5. NOTIFY Bodies.............................................6
5.6. Subscriber generation of SUBSCRIBE requests...............7
5.7. Notifier processing of SUBSCRIBE requests.................7
5.8. Notifier generation of NOTIFY requests....................7
5.9. Subscriber processing of NOTIFY requests..................7
5.10. Rate of notifications....................................8
6. Namespace......................................................8
7. Elements.......................................................8
7.1. AdjacencyName.............................................8
7.2. ReferenceTag..............................................8
7.3. Hostname..................................................8
7.4. ServiceState..............................................9
7.5. Protocol..................................................9
7.6. Version...................................................9
7.7. TransportMethod...........................................9
7.8. Vlan.....................................................10
7.9. MaxChannels..............................................10
7.10. MaxOutboundChannels.....................................10
7.11. MaxBurstRate............................................10
7.12. BurstRateWindow.........................................10
7.13. MaxSustainedRate........................................10
7.14. SustainedRateWindow.....................................10
7.15. TimeToResume............................................10
7.16. NoResponseTimer.........................................11
penno Expires April 20, 2007 [Page 2]
Internet-Draft Peering Policy Event Package October 2006
7.17. InServiceTimer..........................................11
7.18. KeepAliveMethod.........................................11
7.19. KeepAliveInterval.......................................11
8. Interaction with VoIP Federations.............................11
8.1. Within named federations.................................11
8.2. Explicit requirement using draft-lendl-speermint-technical-
policy-00.....................................................11
9. Example.......................................................12
10. Security Considerations......................................12
11. IANA Considerations..........................................13
11.1. Event Package Name......................................13
12. Conclusions..................................................13
13. Acknowledgments..............................................13
14. References...................................................13
14.1. Normative References....................................13
Author's Addresses...............................................15
Intellectual Property Statement..................................15
Disclaimer of Validity...........................................16
Copyright Statement..............................................16
Acknowledgment...................................................16
1. Introduction
In the context of the SPEERMINT working group when two Layer 5
devices (e.g., SIP Proxies) peer, there is a need to exchange peering
policy information. There are specifications in progress in the
SIPPING working group to define policy exchange between an UA and a
domain [4] and providing profile data to SIP user agents [6]. This
document borrows from both and defines a new SIP Event package and
associated semantics to meet the needs of policy exchange between
domains.
Following the terminology introduced in [4], this package uses the
terms Peering Session-Independent and Session-Specific policies in
the following context.
Peering Session-Independent policies include Diffserv Marking,
Policing, Session Admission Control, domain reachabilities, amongst
others. The time period between Peering Session-Independent policy
changes is much greater than the time it takes to establish a call.
Peering Session-Specific polices includes supported connection/call
rate, total number of connections/calls available, current
utilization, amongst others. Peering Session-specific policies can
change within the time it takes to establish a call.
penno Expires April 20, 2007 [Page 3]
Internet-Draft Peering Policy Event Package October 2006
These policies can be Peer dependent or independent, creating the
following peering policy tree definition:
Peer Independent
Session dependent
Session independent
Peer Dependent
Session dependent
Session independent
2. Peering Session-Dependent Policies
We depict below the detailed peering reference architecture. The
Policy Function (PF) is responsible for the exchange of peering
policies.
Peers can exchange policies directly or publish their policies to a
central peering policy server. In order to avoid the N^2 problem, the
use of a policy server that would be responsible for disseminating
the policy information to the appropriate peers is recommended. A
similar idea has been in use for many years in layer 3 peering points
[8].
It is worth mentioning that this policy server does not need to be a
separate physical entity, but can reside logically in one of the SIP
proxies participating on peering point, acting thus as an aggregator
of policies.
+--------+
| Policy |
| Server |
+--------+
^ ^
............................ | | ..............................
. . | | . .
. +-------+ . | | . +-------+ .
. | | . | | . | | .
. | DNS | . | | . | DNS | .
. | 1 | . | | . | 2 | .
. | | . | | . | | .
. +-------+ . | | . +-------+ .
. | . | | . | .
. | . | | . | .
. +-------+ . | | . +-------+ .
. | | . | | . | | .
. | Proxy |--------------| Proxy | .
penno Expires April 20, 2007 [Page 4]
Internet-Draft Peering Policy Event Package October 2006
. | 1 | . . | 2 | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | | . Media . | | .
. | UA 1 |<========================================>| UA 2 | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
............................ ..............................
Figure 1 Peering Detailed Reference Architecture
2.1. Overall Operation
When Layer 5 peering is established between two domains, dynamic
policy information need to be exchanged between SIP Proxies in
different domains. This information will aid the process of Call
routing [7] across domains.
Such information includes, but is not limited to, connection/call
rate, total number of connections/calls available, current
utilization, amongst others.
All SIP Proxies engaged in layer 5 peering that want to be notified
of dynamic policy information (subscribers) send a SUBSCRIBE request
to the policy server specifying the peering-policy event package.
Analogously, SIP Proxies that want to disseminate dynamic policy
information use the PUBLISH method to propagate such information to
the policy server.
When new dynamic policy information is available on the policy
server, it notifies all subscribers of that specific event package.
3. Event Package
This document defines a new SIP events package according to [2]. The
intended methods to use for this event are PUBLISH and
SUBSCRIBE/NOTIFY. A SIP Proxy or B2BUA can exchange peering policies
using either of these methods.
penno Expires April 20, 2007 [Page 5]
Internet-Draft Peering Policy Event Package October 2006
4. Use of PUBLISH Method
A proxy that supports this specification may send dynamic peering
policy information to the policy server using the PUBLISH method.
Another peer wishing to receive this peer's peering policy maintains
a State Agent for the "peering-policy" event package.
5. Event Package Formal Definition
5.1. Event Package Name
This document defines a SIP Event Package as defined in RFC 3265 [2].
The name of the event package defined in this specification is
"peering-policy".
5.2. Event Package Parameters
TBD: Do we want parameters [6] as well or have everything inside the
bodies?
5.3. SUBSCRIBE Bodies
A SUBSCRIBE for the peering-policy package must contain a body that
contains the elements of the Peering Policy Dataset Format (PPDS) for
which the subscriber is interested in receiving notifications. The
notifier will tailor its notifications based on the elements the
subscriber is interested.
5.4. Subscription Duration
A subscription to the peering-policy package is usually established
when a SIP Proxy first engages in Layer 5 peering. A subscription to
the peering-policy package a priori should last as log as the SIP
Proxy is engaged in peering.
Although the rate of notifications can be high, the interest from the
subscriber is to receive notifications as long as the peering
relationship is established. Therefore, it is recommended that the
default subscription duration for this event package should be set to
86400 seconds.
5.5. NOTIFY Bodies
The notification follows the general rules for generating SUBSCRIBE
requests defined in [2]. The notification should contain the elements
requested by the subscriber. If the data associated to some elements
penno Expires April 20, 2007 [Page 6]
Internet-Draft Peering Policy Event Package October 2006
is not available, a special value indicating "not available" should
be sent.
It is possible that a notification contain more elements than the
subscriber requested for the reasons discussed in section 5.8.
5.6. Subscriber generation of SUBSCRIBE requests
The subscriber follows the general rules for generating SUBSCRIBE
requests defined in [2].
5.7. Notifier processing of SUBSCRIBE requests
The general rules for processing SUBSCRIBE requests [2] apply to this
package. More specifically, as each subscription request is received,
the notifier maintains a map of subscriptions to associated requested
elements.
5.8. Notifier generation of NOTIFY requests
Given all the possible elements each subscriber can request, you can
have a scalability problem given the possible number of permutations
and rate of notifications.
The notifier (policy server) can then send a customized notification
for each subscriber if the number is small or a union of the
requested elements in order to reduce the number of different
notifications.
5.9. Subscriber processing of NOTIFY requests
If a notification contains elements that the subscriber did not
request, those elements must be silently discarded. If a notification
does not contain any elements that where requested, an error must be
generated, and the subscription cancelled and possibly reestablished.
The subscriber will use the information received on the notification
messages as an input to the call routing process. The subscriber
might route call to some other peering point or SIP Proxy, reject
calls, bill calls differently, amongst others.
The actual actions that the subscriber will take are not in scope of
this document.
penno Expires April 20, 2007 [Page 7]
Internet-Draft Peering Policy Event Package October 2006
5.10. Rate of notifications
Since peering session specific policies can change with each
established call across the peering interface, the rate of
notifications of certain elements could be very high. For this reason
the maximum rate of notifications should be one every 5 seconds.
Moreover, the actual rate of notifications should be the greater
between the value specified in the SUBSCRIBE request and the default.
TBD: Throttling?
6. Namespace
This specification makes use of XML namespaces [4]. The namespace
URIs for schemas defined in this specification are URNs [7], using
the namespace identifier 'ietf' defined by [8] and extended by [5].
The namespace URN for the MPDF schema is:
urn:ietf:params:xml:ns:peeringdataset
The MIME type for the Media Policy Dataset Format is:
application/peering-policy+xml
7. Elements
7.1. AdjacencyName
This elements names the interconnect relationship. This name is the
"subscription key" for the remote party, and represents the key to
access the relationship from the remote side.
7.2. ReferenceTag
This element is a unique tag assigned to identify this data object
for all subsequent updates/replacements/deletions.
7.3. Hostname
This is the FQDN of the proxy address to use. This may not match the
address of the server providing this data. For example, this data may
be supplied by a centralized policy server, or a centralized proxy
referring to a farm of proxy servers. This element can also be
updated to move services to another proxy in real time.
penno Expires April 20, 2007 [Page 8]
Internet-Draft Peering Policy Event Package October 2006
7.4. ServiceState
This is either "in service", "no new calls", "out of service". The
service state can be changed at any time. Transitioning to "in
service" will indicate that calls can be sent immediately.
Transitioning to "no new calls" will permit existing calls to
continue. Transitioning to "out of service" will indicate that all
calls should be dropped.
The out of service mechanism is a way for an adjacency to quickly and
easily communicate that all communication is terminated. This could
be useful when there is a catastrophic failure - and one side looses
session state. The "out of service" for the defined adjacency will
communicate to the other side that all sessions using this particular
adjacency need to be terminated.
7.5. Protocol
SIP is the only answer here for now. [Optional - this may not be
needed]
7.6. Version
Currently rfc3261 or rfc2543 are the only answers. This will indicate
if the proxy supports strict or loose routing. [Optional - this may
not be needed]
7.7. TransportMethod
This can be rfc3161 (UDP/TCP/TLS based on protocol/port/packet size),
UDP Only (Fragment Packets larger than 1368 bytes), Dynamic TCP,
Static TCP, SCTP.
Dynamic TCP is call-by-call establishment of TCP, verses staying
connected. UDP fragmentation is actually something that we deal with
today. According to the standard, one is supposed to switch to TCP to
avoid fragmentation, but many implementations actually only support
UDP and UDP fragmented packets. This is an attribute of an adjacency
that can't be guessed at, since its non-standard behavior.
This may only be required when exceptional (non 3261) behavior is
expected - such as fragmenting UDP packets.
penno Expires April 20, 2007 [Page 9]
Internet-Draft Peering Policy Event Package October 2006
7.8. Vlan
Vlan tag to use on all packets to be sent to his proxy. This may be
specified for security reasons or L2 switching reasons. A vlan tag of
0 means no tagging is performed.
7.9. MaxChannels
This element represents the maximum total count of dialogues that
this proxy can support.
7.10. MaxOutboundChannels
This element represents the maximum total count of outbound dialogues
from a given peer. This used in combination with the MaxChannels can
control the ratio of inbound to outbound. This ratio is important for
some bidirectional interconnects that may have service guarantees.
For example, a carrier with 10 customers may have contractual SLAs
based on expected volume levels. So there may be one customer that is
only permitted 20 calls at location one, and 40 calls at location
two. It may be useful to have notification mechanisms to maintain
this SLA level dynamically (switching these possibly, or adding a new
location).
7.11. MaxBurstRate
Maximum call setup rate within the BurstWindow
7.12. BurstRateWindow
Number of seconds to use for determining MaxBurstRate
7.13. MaxSustainedRate
Maximum sustained call rate within the SustainedRateWindow
7.14. SustainedRateWindow
Number of seconds to use for determining MaxSustainedRate
7.15. TimeToResume
When a constraint is reached (Burst/Sustained/Max Channels), this
attribute informs how long to pause before attempting to use this
proxy again.
penno Expires April 20, 2007 [Page 10]
Internet-Draft Peering Policy Event Package October 2006
7.16. NoResponseTimer
How long for a proxy to be unresponsive before it is automatically
taken out of service.
7.17. InServiceTimer
How long the proxy should be responsive after an out of service
condition (keepalive failure/no response timer exceeded) before new
calls should be attempted.
7.18. KeepAliveMethod
Defines the method for performing keep alive. This includes 'stun',
'ping', 'crlf'.
7.19. KeepAliveInterval
Defines the interval between keep-alives.
8. Interaction with VoIP Federations [14]
8.1. Within named federations.
A federation can define in its internal rules, which don't need to be
published beyond the membership that for calls within that federation
draft-penno-sipping-peering-package-00 is required.
This makes implementation of that package a requirement of joining
this specific federation.
8.2. Explicit requirement using [13]
We're now outside the federation scheme. Nonetheless, draft-lendl-
speermint-technical-policy-00 enables any ITSP to indicate his
willingness to accept calls if the peering package SUBSCRIPTION has
been used.
e.g. big-voip-network.net could use an entry like the one depicted
below in its domain to announce this requirement. (additionally, he
can also indicate federation memberships where perhaps the event
package isn't part of the federation ruleset)
penno Expires April 20, 2007 [Page 11]
Internet-Draft Peering Policy Event Package October 2006
IN NAPTR 10 10 ( ; order priority
"U" "D2P+SIP:std" ; flags service
"!^.*$!urn:ietf:id:penno-sipping-peering-package-00!" . ; regexp
repl
)
9. Example
Since the originating peer proxy does not know if the destination AOR
is a PF or a SF, it must progress with a normal dialog request with
the assumption it is a SF. In the event a request fails due to an
authentication failure (401 Unauthorized), and no known
authentication credentials exist or no longer appear to be working,
the requesting proxy may issue a SUBSCRIBE request to the attempted
peer's AOR received through the discovery phase. The SUBSCRIBE
request should be a request to attain a, currently, undefined peering
policy event package. In some cases, the requesting proxy already
knows it must attain the peering policy event package, and may forego
the initial INVITE attempt and issue a SUBSCRIBE request instead.
Once this phase is completed, after extracting and following any
specific received policies, the authentication phase is attempted as
the policy permits or requires. The following message flow provides
an example of the policy exchange phase.
Peer Proxy Policy Server
| |
| INVITE |
|------------------------------->|
| 401 Unauthorized |
|<-------------------------------|
| |
| SUBSCRIBE |
+---->|------------------------------->|
| | 202 Accepted |
Policy Exchange | |<-------------------------------|
-----------------| | Notify |
Phase | |<-------------------------------|
| | 200 OK |
+---->|------------------------------->|
| INVITE |
|------------------------------->|
10. Security Considerations
To prevent these attacks, a subscriber using this event package
SHOULD authenticate the notifier (i.e. the policy server) before
penno Expires April 20, 2007 [Page 12]
Internet-Draft Peering Policy Event Package October 2006
disclosing session information or accepting a session policy. This
requires the subscriber to perform server authentication which can be
done, for example, via TLS or another transport mechanism.
Similarly, notifiers SHOULD authenticate subscribers using any of the
techniques available through SIP, including digest, S/MIME, TLS or
other transport specific mechanisms.
11. IANA Considerations
11.1. Event Package Name
This specification registers an event package, based on the
registration procedures defined in RFC 3265 [2]. The following is
the information required for such a registration:
Package Name: peering-policy
Package or Template-Package: This is a package.
Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX
with the RFC number of this specification).
Person to Contact:
12. Conclusions
TBD
13. Acknowledgments
Brian Rosen and Michael Hammer for their contributions to the policy
subject on the SPEERMINT mailing list.
14. References
14.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
penno Expires April 20, 2007 [Page 13]
Internet-Draft Peering Policy Event Package October 2006
[3] 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.
[4] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML",
W3C REC REC-xml-names-19990114, January 1999.
[5] Mealling, M., "The IETF XML Registry", draft-mealling-iana-
xmlns-registry-05 (work in progress), June 2003.
[6] Burger, E (Ed.), "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006
[7] Moats, R., "URN Syntax", RFC 2141, May 1997.
[8] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[9] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for
Session Initiation Protocol (SIP) Session Policies", draft-
ietf-sipping-session-policy-framework-00 (work in progress)
[10] Petrie, D., "A Framework for Session Initiation Protocol User
Agent Profile Delivery", draft-ietf-sipping-config-framework-08
(work in progress), March 2006.
[11] Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint-
terminology-01 (work in progress), May 2006.
[12] T. Bates, E. Chen, R. Chandra, "BGP Route Reflection: An
Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April
2006
[13] Lendl, O., "Publishing Policies using the Domain Policy DDDS
Application", draft-lendl-speermint-technical-policy-00 (work
in progress), August 2006.
[14] Habler, M., et al., "A Federation based VOIP Peering
Architecture", draft-lendl-speermint-federations-03.txt,
September 2006.
penno Expires April 20, 2007 [Page 14]
Internet-Draft Peering Policy Event Package October 2006
Author's Addresses
Reinaldo Penno
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA
USA
Email: rpenno@juniper.net
Daryl Malas
Level 3 Communications LLC
1025 Eldorado Blvd.
Broomfield, CO 80021
USA
EMail: daryl.malas@level3.com
Patrick J. MeLampy
Acme Packet, Inc
71 Third Avenue
Burlington, MA 01803
Email: PMelampy@acmepacket.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.
penno Expires April 20, 2007 [Page 15]
Internet-Draft Peering Policy Event Package October 2006
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 April 20, 2007 [Page 16]