Internet DRAFT - draft-khan-ip-serv-peer-arch
draft-khan-ip-serv-peer-arch
Network Working Group R. Penno
Internet Draft Juniper Networks
Expires: December 2006 D. Malas
Level 3
S. Khan
Sprint
A. Uzelac
Global Crossing
M. Hammer
Cisco Systems
June 17, 2006
SPEERMINT Peering Architecture
draft-khan-ip-serv-peer-arch-03
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 2006.
Abstract
khan Expires December 17, 2006 [Page 1]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
This document defines a SPEERMINT peering reference architecture, its
functional components and peering interface functions.
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...................................................2
2. Network Context................................................4
3. Reference Peering Architecture.................................4
4. Peering Interface Functions....................................5
4.1. Location Function (LF)....................................6
4.2. Operation Function (OF)...................................7
4.3. Signaling Function (SF)...................................7
4.4. Media Function (MF).......................................8
4.5. QoS Function (QF).........................................8
4.6. Application Function (AF).................................9
5. Call Control and Media Control Deployment Options..............9
6. Security Considerations.......................................10
7. IANA Considerations...........................................10
8. Conclusions...................................................10
9. Acknowledgments...............................................11
10. References...................................................11
10.1. Normative References....................................11
10.2. Informative References..................................11
Author's Addresses...............................................12
Intellectual Property Statement..................................12
Disclaimer of Validity...........................................13
Copyright Statement..............................................13
Acknowledgment...................................................13
1. Introduction
The objective of this document is to define a reference peering
architecture in the context of SPEERMINT. In this process, we define
a peering reference architecture, its functional components, and
peering interface functions from the perspective of a real-time
application (Voice and Multimedia) IP Service provider network.
This reference architecture applies mainly to SIP-based voice and
multimedia traffic only and has not considered traditional Internet
traffic such as HTTP.
khan Expires December 17, 2006 [Page 2]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
IP Layer peering is outside the scope of SPEERMINT at this time;
thus, we do not include them in the SPEEMINT Peering Architecture.
Note that IP Routers are not shown in the subsequent figures so that
the focus is on Layer 5 protocol aspects.
+------------------+
| Public |
| Peering Function |
| Location Server |
+------------------+
|
-----
+-----------+ / \ +-----------+
|Enterprise | -- -- |Enterprise |
|Provider A |-----------/ \-----------|Provider B |
+-----------+ -- -- +-----------+
/ Public \
| Internet |
\ (Layer 3) /
+-----------+ -- -- +-----------+
|Service |-----------\ /-----------|Service |
|Provider C | -- -- |Provider D |
+-----------+ \_____/ +-----------+
| Layer 3 Peering
| Point (out of scope)
-----
+-----------+ / \ +-----------+
|Enterprise | -- -- |Enterprise |
|Provider E |-----------/ \-----------|Provider F |
+-----------+ -- Service -- +-----------+
/ Provider \
| Private |
\ Internet /
+-----------+ -- (Layer 3) -- +-----------+
|Service |-----------\ /-----------|Service |
|Provider G | -- -- |Provider H |
+-----------+ \____/ +-----------+
|
+------------------+
| Private |
| Peering Function |
| or |
|Federation Entity |
+------------------+
Figure 1: Peering Network Context
khan Expires December 17, 2006 [Page 3]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
2. Network Context
Figure 1 shows an example network context. Two or more providers on
either the public Internet or private Layer 3 networks may form a SIP
(Layer 5) federation. The public or private peering location server
function enables discovery of federations and all provider peering
points. Subsequent exchanges with those provider peering points will
enable discover of policy and additional signaling and media peering
Note that Figure 1 allows for the following potential interconnect
scenarios:
o Enterprise to Enterprise across the public Internet
o Enterprise to Service Provider across the public Internet
o Service Provider to Service Provider across the public Internet
o Enterprise to enterprise across a private internet
o Enterprise to Service Provider across a private internet
o Service Provider to Service Provider across a private internet
Note also that the nature of the Service Provider is intentionally
ambiguous, so it encompasses both VoIP SP and other Application SP.
Federation Entity
We define federation as a providers' group that has contractual
agreements on various aspects of peering relationship such as common
administrative policy, settlement, and terminating calls. The members
of a federation may jointly use a set of entities such as location
function, application servers, subscriber databases, SIP proxies ,
and/or platforms that synthesize various SIP and non-SIP based
applications.
Next Hop:
A next hop may be a direct peer or a transit peer.
3. Reference Peering Architecture
Figure 2 shows the functional elements that act as border functions
for exchanging information across the peering interface.
khan Expires December 17, 2006 [Page 4]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
+----+
| LF |
------- +----+ -------
/ \ | | / \
| LF---+ +---LF |
| | | |
| OF-----------OF |
| | | |
| IP SF-----------SF IP |
| Service | | Service |
|Provider MF---------MF Provider|
| X | | Y |
| QF-----------QF |
| | | |
| AF-----------AF |
| | | |
\ / \ /
------- -------
Figure 2: Reference Peering Architecture
Within the Layer-5 Service Provider's network there may be IP phones,
Proxies, B2BUA, Interactive Voice Response (IVR), and other hosts
that originate or terminate L5 signaling and L5 media paths. The
Layer-5 SP may also operate interworking Gateways to the PTSN and
Wireless networks. These internal elements and external elements are
beyond the scope of the Layer-5 Peering point.
A real-time application (Voice and Multimedia) IP Service provider
network contains functions of SIP/SIPPING/SIMPLE related RFCs in
general and RFC3261 [2] in particular. Examples of these functions
are SIP Proxies, SIP UAs, and B2BUAs. In addition, these IP Service
providers' networks contain IP Routers, Application servers, and
databases. The network may also contain private ENUM and DNS.
A real-time application (Voice and Multimedia) IP Service provider
interconnects with other real-time application (Voice and Multimedia)
IP Service providers through a set of peering interface functions
which are discussed next.
4. Peering Interface Functions
An IP Service peering interface can be divided into various planes.
This document proposes the following decomposition of functions:
o Location Function (LF): Purpose is to enable discovery of the SF
or OF peering point. (Section 4.1)
khan Expires December 17, 2006 [Page 5]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
o Operation Function (OF): Purpose is to enable discovery and
exchange of policy and parameters to be used in with the SF
peering point. (Section 4.2)
o Signaling Function (SF): Purpose is to enable the discovery of
endpoints and assist in discovery and exchange of parameters to be
used with the MF peering point. (Section 4.3)
o Media Function (MF): Purpose is to enable the interconnection of
media paths between endpoints. (Section 4.4)
o QoS Function (QF): Purpose is to negotiate and reserve bandwidth
resources, as well as police and provide measurements for media
paths. (Section 4.5)
o Application Function (AF): TBD (Section 4.5)
Note that each of these functions must address security
considerations.
4.1. Location Function (LF)
The LF provides a way to discover the next hop signaling function
(SF) in a peering relationship. (do we . This can be accomplished
through mutually trusted DNS, ENUM, SIP Redirect Server or
functionally future database.
The function of the LF is to provide a trusted registry database for
next hop in a peering relationship. The registry can be either
internal or external to the federation if federation exists. It may
take multiple queries to resolve the next hop. Possible examples of
a LF are:
o ENUM:
o Input: E.164
o Output: SIP AoR of a next hop Signaling Function (SF) or OF.
o DNS:
o Input: Domain Name from the AoR of an end user
o Output: SIP AoR of the next hop Signaling Function (SF)
o Global Public Database (if hierarchical system exists):
khan Expires December 17, 2006 [Page 6]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
o Input: Local Signaling Function address (local context). The
domain name of an end user or the domain name of a destination
service provider
o Output: The next hop reachable address.
o SIP Redirect Server
o Input: E.164 address or domain Name from the AoR of an end user
o Output: SIP AoR of the next hop Signaling Function (SF)
Capability of ENUM resolves number portability, SIP mobility resolves
session layer mobility, and IP mobility resolves micro-mobility.
Thus, the LF does not address the following issues:
o Number portability function
o Mobility function
4.2. Operation Function (OF)
Operational function is optional. Examples of O&M Function (OF) are:
o Dynamic subscribe, notify, and exchange of policy information and
feature information among providers (See SIPPING Policy document
and Peering Policy document)
o SLA data exchange
o Accounting data exchange: Call Detail Record's (CDR's) MAY be
collected to be utilized by the peering operators. Based on the
application, the format should be an open standard for common
consumption of billing systems. Operators may use this data for a
number of reasons, including billing in the event the peering
relationship becomes asymmetric (unbalanced traffic flow) or there
is a Tier 1 to Tier 2 relationship. In order to limit the
potential for billing systems to impact the OF, a separate server
should be created to maintain all records collected from a single
interconnection to any number of OF's.
4.3. Signaling Function (SF)
The SF performs Layer 5 peering functions i.e., SIP signaling and
control functions at the interconnect interface. Examples of SF from
SIP RFCs are SIP Proxy and SIP B2BUA. Tasks that the SF must (must?)
perform are:
khan Expires December 17, 2006 [Page 7]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
Session Admission Control (SAC): This is an optional feature. A
provider may or may not implement SAC. Define SAC: TBD
Note, in case a session is rejected because of the SAC
implementation, the session rejecting provider Y needs to inform the
originating provider X, the cause of rejection with appropriate SIP
error message. The SPEERMINT routing architecture message flow
document will describe these messages.
SIP Denial of Service (DoS) protection: Providers will most likely
implement DoS protection mechanism. Define DoS: TBD
Note, in case sessions are rejected due to the DoS protection
implementation, the session rejecting provider Y needs to inform the
originating provider X ,the cause of rejection with appropriate SIP
error messages. The SPEERMINT routing architecture message flow
document will describe these messages. Note also that this feature
implementation is optional since DoS issue needs to be dealt with the
case by case basis.
SIP Topology Hiding (THIG): This optional feature will hide internal
layer 5 architecture of a service provider and its end users.
SIP security, privacy and encryption: The SF may support Security
functions to provide authentication, privacy (encryption) and message
integrity functions. These functions may be provided by using IPSec
or TLS.
4.4. Media Function (MF)
Media is composed of encoded Voice or Video carried in RTP streams
carried within Layer 3 IP streams. The MF may transform voice
payload from one coding (e.g., G.711) to another (e.g., EvRC). Other
Media Functions (MF) include media security, privacy and encryption.
4.5. QoS Function (QF)
The QF typically would be at the IP border between service providers
and ensure that incoming and outgoing packets are QOS-marked
correctly according to federation or peer policy. Its implementation
is OPTIONAL unless government regulations mandate required
implementation.
Separate IETF documents address SIP priority and QoS issues. It is
desirable that the various standards bodies (e.g., IETF, ITU, and
3GPP) converge on a compatible set of SIP priority header mappings
khan Expires December 17, 2006 [Page 8]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
particularly with special attention to the emergency services
(ETS/WPS).
4.6. Application Function (AF)
TO DO: Example and use case
5. Call Control and Media Control Deployment Options
The peering functions can either be deployed along the following two
dimensions depending upon how the SF and the MF along with IP
functions are implemented:
Composed or Decomposed: Addresses the question whether the media
paths must flow through the same physical and geographic nodes as the
call signaling,
Centralized or Distributed: Addresses the question whether the
logical and physical peering points are in one geographical location
or distributed to multiple physical locations on the service provider
network.
In a composed model, SF, and MF functions are implemented in one
entity.
Provider A Provider B
---------- . . ----------
/ \ . . / \
| | . _ . | |
| +----+ . / \_ . +----+ |
| | SF |<-----/ \------| SF | |
| e.g. +-+--+ . /Transit\ . | | |
| MGCP-> | | . / IP \ . | | |
| +-+--+ . \ Provider| . | | |
| | MF |<~~~~\(Option)|~~~~| MF | |
| +----+ . \ / . +----+ |
| | . \__ _/ . | |
\_________ / . . \________ _/
---------- ----------
--- Signal (SIP)
~~~ Bearer (RTP/IP)
... Scope of peering
Figure 3: Decomposed v. Composed Peering
khan Expires December 17, 2006 [Page 9]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
The advantage of composed peering architecture is that one-device
solves all peering issues. Disadvantage examples of this architecture
are single point failure, bottle neck, and complex scalability.
In a decomposed model, SF and MF are implemented in separate
entities. Signaling functions are implemented in a proxy and media
functions are implemented in another device. The scaling of
signaling versus scaling of media may differ between applications.
Decomposing allows each to follow a separate migration path.
This model allows the implementation of M:N model where one SF is
associated with multiple peering routers and one peering router is
associated with multiple peering proxies. Generally, a vertical
protocol such as MGCP associates the relationship between a peering
proxy and a peering router. This architecture reduces the potential
of single point failure. This architecture, allows separation of the
policy decision point and the policy enforcement point. An example of
disadvantages is the scaling complexity because of the M:N
relationship and latency due to the vertical control messages between
entities.
6. Security Considerations
In all cases, cryptographic-based security should be maintained as an
optional requirement between peering providers conditioned on the
presence or absence of underlying physical security of peer
connections, e.g. within the same secure physical building.
In order to maintain a consistent approach, unique and specialized
security requirements common for the majority of peering
relationships, should be standardized within the IETF. These
standardized methods may enable capabilities such as dynamic peering
relationships across publicly maintained interconnections.
TODO: Address RFC-3552 BCP items.
7. IANA Considerations
There are no IANA considerations at this time.
8. Conclusions
The proposed peering reference architecture decomposes the peering
interface into a set of well defined functions. Such an arrangement
allows each function to the specified and evolved separately.
khan Expires December 17, 2006 [Page 10]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
9. Acknowledgments
Mark Evans from Sprint-Nextel Corporation helped to define security
related signaling functions.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[2] 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)
[3] Sohel Khan et al., "Conceptual Deployment Scenarios of
Session/Border Control(S/BC) Functions", expired draft-sohel-
sipping-s-bc-concept-arch-00.txt
khan Expires December 17, 2006 [Page 11]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
Author's Addresses
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
Daryl Malas
Level 3 Communications LLC
1025 Eldorado Blvd.
Broomfield, CO 80021
USA
EMail: daryl.malas@level3.com
Adam Uzelac
Global Crossing
1120 Pittsford Victor Road
PITTSFORD, NY 14534
USA
Email: adam.uzelac@globalcrossing.com
Mike Hammer
Cisco Systems
13615 Dulles Technology Drive
Herndon, VA 20171
USA
Email: mhammer@cisco.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
khan Expires December 17, 2006 [Page 12]
Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006
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 (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.
khan Expires December 17, 2006 [Page 13]
