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]