Speermint Working Group R. Penno Internet Draft Juniper Networks Intended status: Informational H. Kaplan, Ed. Expires: November 2008 Acme Packet D. Malas CableLabs S. Khan Comcast A. Uzelac Global Crossing July 14, 2008 SPEERMINT Routing Architecture Message Flows draft-ietf-speermint-flows-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/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 January 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Kaplan, et al Expires January 14, 2009 [Page 1] Internet-Draft draft-ietf-speermint-flows-03 July 2008 Abstract This document describes example message flows associated with the SPEERMINT routing architecture, relative to various peering scenarios. 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]. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". Table of Contents 1. Introduction...................................................3 2. Definitions....................................................3 3. Peering Scenarios..............................................3 4. Basic Peering Message Flow.....................................7 5. On-Demand Peering..............................................9 5.1. Transport Layer Security..................................9 6. Static Peering................................................11 6.1. TLS......................................................11 6.2. IPSec....................................................12 6.3. Co-Location..............................................13 7. Federation Based Peering......................................13 7.1. Central Federation Proxy.................................13 7.2. TLS Based Federation.....................................14 8. Media Relay...................................................14 9. Peering Message Flow Phases...................................15 9.1. Discovery Phase..........................................16 9.2. Security Establishment Phase.............................17 9.3. Signaling Exchange Phase.................................17 9.4. Media Exchange Phase.....................................18 10. Security Considerations......................................19 11. IANA Considerations..........................................19 12. Acknowledgments..............................................19 13. References...................................................19 13.1. Normative References....................................19 13.2. Informative References..................................20 Author's Addresses...............................................20 Intellectual Property Statement..................................21 Full Copyright Statement.........................................22 Acknowledgment...................................................22 Kaplan, et al Expires January 14, 2009 [Page 2] Internet-Draft draft-ietf-speermint-flows-03 July 2008 1. Introduction This document shows the message flows associated with the most relevant SPEERMINT routing architecture peering scenarios. Most of the message diagrams were based on previous work described within existing IETF standards documents. The document focuses on the messages exchanged for the purpose of Layer 5 peering [7] between two domains. Messages exchanged for the purpose of setting up SIP sessions within a domain are considered out of scope and are already defined in other IETF documents. 2. Definitions SSP: SIP Service Provider, the administrative entity providing SIP services utilizing SIP. Note that an SSP may be a traditional Service Provider, an Enterprise, or any administrative domain context. LUF: Look-Up Function, the functional step(s) necessary to determine for a given SIP request, which terminating domain it should be sent to. LRF: Location Routing Function, the functional step(s) necessary to determine for a given SIP request's terminating domain, the path to follow to reach the terminating domain. Routing: In the context of this document, it is forwarding of an out- of-dialog SIP request. SED: Session Establishment Data, the LUF and LRF data needed and used to route a SIP request to the next-hop(s) associated with reaching the terminating domain. SBE: Signaling-path Border Element, the SIP node that represents the logical boundaries between SSP domains (a.k.a., the signaling portion of an SBC, I-BCF, etc.). DBE: Data-path Border Element, the node that relays media between the logical boundaries of SSP domains (a.k.a., the media portion of an SBC, I-BGF, etc.). 3. Peering Scenarios This draft separates the Layer 5 peering scenarios into two major peering scenarios. Kaplan, et al Expires January 14, 2009 [Page 3] Internet-Draft draft-ietf-speermint-flows-03 July 2008 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, without a pre-existing relation ship. This is sometimes referred as the "email" model. o Static: In this scenario the peering relationship between proxies A and B is statically pre-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 from signaling, only following the IP routed transport path when crossing peering domains. Alternatively, media for a given session can be directed to traverse the same SIP device used for Layer 5 peering, i.e., the same device that handles signaling when crossing domains. This produces three different models: o Media-direct: In this model SIP proxies perform Layer 5 peering, while media is sent directly between the User Agent's (UA's) involved in the session, as shown in Figure 1. Therefore signaling and media follow different paths. o Integrated: In this model, the device that performs Layer 5 SIP peering also processes the associated media when crossing domains, as shown in Figure 2. This function is usually referred to as media relay and is usually performed by a B2BUA or SBC (Session Border Controller), called an SBE in this document. See [6] for a complete discussion of SBC functions. We will refer to this picture throughout this document. o Decomposed: In this model, media is relayed by a Data Border Element which is physically separated from the SBE. A control protocol, typically H.248 or MGCP, is used by the SBE to control the DBE. From the UA and peering domain's perspective, the decomposed SBE and DBE do not function any differently than an integrated SBC. For the purposes of this document, one can consider this model as just a variant of the integrated. Kaplan, et al Expires January 14, 2009 [Page 4] Internet-Draft draft-ietf-speermint-flows-03 July 2008 ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | DNS | . . | DNS | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . +-------+ . . +-------+ . . | | . . | | . . | Proxy |--------------| Proxy | . . | 1 | . . | 2 | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | | . Media . | | . . | UA 1 |<========================================>| UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 1: Basic Peering Picture (media-direct) Kaplan, et al Expires January 14, 2009 [Page 5] Internet-Draft draft-ietf-speermint-flows-03 July 2008 The integrated model is shown below: ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | DNS | . . | DNS | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . +-------+ . . +-------+ . . | SBE | . . | SBE | . . | & |--------------| & | . . | DBE |**************| DBE |\ . . /| | . . | | \ . . / +-------+ . . +-------+* \ signaling . . / * . . * \ . . / * . . * \ . . / * . . * \ . . / * media . . * \ . . / * . . * \ . . / * . . * \ . . / * . . * \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 2: Integrated Peering Picture Kaplan, et al Expires January 14, 2009 [Page 6] Internet-Draft draft-ietf-speermint-flows-03 July 2008 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 this document. The decomposed model is shown below: ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | DNS | . . | DNS | . . | 1 | . . | 2 | . . | | . . | | . . +-------+ . . +-------+ . . | . . | . . | . . | . . +-------+ . . +-------+ . . /| SBE |--------------| SBE |\ . . / +-------+ +-------+ \ . . / +-------+ +-------+ \ . . / | DBE |**************| DBE | \ . . / +-------+ . . +-------+* \signaling . . / * . . * \ . . / * . . * \ . . / * . . * \ . . / * media . . * \ . . / * . . * \ . . / * . . * \ . . / * . . * \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 3: Decomposed Peering Picture. 4. Basic Peering Message Flow This section depicts the "basic" Peering message flow. This does not imply this is the most common peering scenario - just a baseline. The various scenarios differ mostly of how and when peering is implemented. As stated earlier, peering can be establish dynamically Kaplan, et al Expires January 14, 2009 [Page 7] Internet-Draft draft-ietf-speermint-flows-03 July 2008 following the arrival of a message at a border proxy, or statically based on an agreement between both domains. Alice Proxy 1 DNS Proxy 2 Bob | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | | | NAPTR | | | | | Query | | | | |--------->| | | | | NAPTR | | | | | Reply | | | | |"SIP+D2U" | | | | |<---------| | | | | SRV | | | | | Query | | | | |--------->| | | | | SRV | | | | | Reply | | | | |<---------| | | | | | | | | Peering | | | | Phase | | | | [On-Demand] | | | |<------------------>| | | | INVITE | | | |------------------->| INVITE | | | 100 |---------->| | |<-------------------| | | | | 180 | | | 180 |<----------| | 180 |<-------------------| | |<-------| | 200 | | | 200 |<----------| | 200 |<-------------------| | |<-------| | | | ACK | | | |------->| ACK | | | |------------------->| ACK | | | |---------->| | Both Way RTP Media | |<=======================================>| Kaplan, et al Expires January 14, 2009 [Page 8] Internet-Draft draft-ietf-speermint-flows-03 July 2008 | | | BYE | | | BYE |<----------| | BYE |<-------------------| | |<-------| | | | 200 | | | |------->| 200 | | | |------------------->| 200 | | | |---------->| | | | | In the integrated 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 | |<======>|<==================>|<=========>| | | | | The following sections show the message flows in several different scenarios broken in two categories: on-demand and static. 5. 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). 5.1. Transport Layer Security In case this is in fact the first SIP request between two SSPs in an on-demand peering relationship, then the SIP request will trigger the establishment of the TLS connection. Otherwise it is assumed the TLS connection has been established by some other means and may be reused. Kaplan, et al Expires January 14, 2009 [Page 9] Internet-Draft draft-ietf-speermint-flows-03 July 2008 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 | | | Kaplan, et al Expires January 14, 2009 [Page 10] Internet-Draft draft-ietf-speermint-flows-03 July 2008 |------->| 200 | | | |------------------->| 200 | | | |---------->| | | | | [TBD: add TLS connection for upstream requests?] 6. Static Peering In the static peering scenario the relationship between proxies A and B is not driven by a SIP request, but before-hand through manual provisioning. 6.1. TLS In this model a TLS connection between proxies A and B is provisioned following an agreement between the two domains. Creation of the TLS connection may be established through previous SIP message exchanges, or by continuous message exchange such as OPTIONS requests/responses. If Mutual-TLS is used, reverse-path requests may use the same connection as defined in [13], or separate TLS connections may be used for each request direction. Kaplan, et al Expires January 14, 2009 [Page 11] Internet-Draft draft-ietf-speermint-flows-03 July 2008 6.2. IPSec In this model an IPSec connection between proxies A and B is provisioned following an agreement between the two domains. Typically either transport-mode ESP is used for SIP signaling only, or tunnel-mode is used for both signaling and media. If tunneling is used, media-relay must be performed as described later. [Note: not all SIP messages shown] Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | [Peering] | | | | IPSec Connection | | | |<------------------>| | | | | | | \ / \ / \ / \ / \ / | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | \ / \ / \ / \ / \ / | | BYE |<----------| | BYE |<-------------------| | |<-------| | | | 200 | | | Kaplan, et al Expires January 14, 2009 [Page 12] Internet-Draft draft-ietf-speermint-flows-03 July 2008 6.3. Co-Location In this scenario the two proxies are co-located in a physically secure location and/or are members of a segregated network, such as a VPN. In this case messages between Proxy 1 and Proxy 2 would be sent as clear text. Alice Proxy 1 DNS Proxy 2 Bob | | | | | | | | | | | [Peering] | | | | Co-Location | | | |<------------------>| | | | | | | \ / \ / \ / \ / \ / | | | | | | INVITE | | | | |------->| | | | | 100 | | | | |<-------| | | | \ / \ / \ / \ / \ / | | BYE |<----------| | BYE |<-------------------| | |<-------| | | | 200 | | | 7. Federation Based Peering Multiple SSP's may be members of the same Federation, such that their policies and relationships are defined to be the same for a given federation. Federations are one way for a source and destination network to find a common set of procedures for peering. 7.1. Central Federation Proxy Federation rules can dictate that calls are to be routed via a federation-maintained central SIP proxy. In that case no further NAPTR/SRV/A lookups are made. Instead, the INVITE will be sent directly via a preconfigured connection to that proxy. This proxy acts as a redirect proxy. Kaplan, et al Expires January 14, 2009 [Page 13] Internet-Draft draft-ietf-speermint-flows-03 July 2008 The following message flow provides an example describing this process: Peer Proxy Federation Proxy Peer Proxy Bob | | | | | INVITE | | | |--------------->| | | | 302 | | | |<---------------| | | | ACK | | | |--------------->| | | | INVITE | | |-------------------------------->| INVITE | | 100 |--------------->| |<--------------------------------| 180 | | 180 |<---------------| |<--------------------------------| | | | 200 | | 200 |<---------------| |<--------------------------------| | | ACK | | |-------------------------------->| ACK | | |--------------->| | Both Way RTP Media | |<================================================>| | | BYE | | BYE |<---------------| |<--------------------------------| | | 200 | | |-------------------------------->| 200 | | |--------------->| 7.2. TLS Based Federation One of the simplest cases is a TLS based federation. In that case the federation rules may prescribe the default NAPTR/SRV lookups and only affect the selection of the correct X.509 certificate for the TLS connection. 8. Media Relay In the event that a source and/or destination SSP are part of a private network, or peer through a private network, the SSP peers Kaplan, et al Expires January 14, 2009 [Page 14] Internet-Draft draft-ietf-speermint-flows-03 July 2008 must enable the SIP signaling and media to route between the peers. This process is implemented by an SBE and DBE, either in an integrated or decomposed model. The core of the process is media relaying, whereby the SBE forces the relay of media through its DBE by modifying the SDP. 9. Peering Message Flow Phases The message flow phases are Discovery, Security Establishment, Signaling Exchange, and Media Exchange. The following flow provides an overview of the phases. Each of the phases is described individually in the following subsections. For the following diagram, the signaling and media exchange phase descriptions have been omitted for clarity purposes, because their functionality has not changed for the purposes of peering. However, they have been explained further in the following subsections. Alice Peer Proxy DNS Peer Policy/Proxy Bob | | | | | |INVITE | | | | |----------->| | | | | 100| | | | |<-----------| | | | |NAPTR Query | | | +---->|--------------->| | | | | NAPTR Reply| | | Discovery Phase | |<---------------| | | ----------------| |SRV Query | | | | |--------------->| | | | | SRV Reply| | | +---->|<---------------| | | | | | | Security Exch. | [TLS Connection] | | --------------------->|<--------------------------->| | Phase | INVITE | | |---------------------------->|INVITE | | | 100 Trying |------------->| | |<----------------------------| 180 Ringing| | | 180 Ringing |<-------------| | 180 Ringing|<----------------------------| 200OK | |<------------| 200OK |<-------------| | 200OK |<----------------------------| | |<------------| | | | ACK | | | |------------>| ACK | | Kaplan, et al Expires January 14, 2009 [Page 15] Internet-Draft draft-ietf-speermint-flows-03 July 2008 | |---------------------------->|ACK | | | |------------->| | | Both Way RTP Media | | |<========================================================>| | | | BYE | | | BYE |<-------------| | BYE |<----------------------------| | |<------------| | | | 200OK | | | |------------>| 200OK | | | |---------------------------->|200OK | | | |------------->| 9.1. Discovery Phase The first phase of static or dynamic peering requests is discovery. The discovery process can be summarized by querying the Location Routing Function (LRF) to determine the next phase in the message flow. The discovery phase can take place via a local or external federation location function. Examples of the function may be comprised of an ENUM/DNS or redirect server. After the discovery phase has completed, the peering process will progress to a subsequent phase, usually the policy or authentication phase. The following message flows provide examples of the discovery phase. Discovery phase utilizing an ENUM/DNS server as a location function: Alice Peer Proxy DNS Peer Proxy | | | | |INVITE | | | |----------->| | | | 100| | | |<-----------| | | |NAPTR Query | | +---->|--------------->| | | | NAPTR Reply| | Discovery Phase | |<---------------| | -----------------| |SRV Query | | | |--------------->| | | | SRV Reply| | +---->|<---------------| | |INVITE | |------------------------------->| Kaplan, et al Expires January 14, 2009 [Page 16] Internet-Draft draft-ietf-speermint-flows-03 July 2008 Discovery phase utilizing a REDIRECT server as a location function: Peer Proxy Federation Proxy Peer Proxy | | | | INVITE | | +---->|--------------->| | Discovery Phase | | 302 | | -----------------| |<---------------| | | | ACK | | +---->|--------------->| | | INVITE | |------------------------------->| 9.2. Security Establishment Phase The security establishment phase follows the described methods in previous sections of this document. This phase follows standard methods described in [2], so the following flow provides an example of this phase, but does not incorporate all possibilities. This phase assumes the previous phases were successfully completed or purposefully omitted per peering implementation. Peer Proxy Peer Proxy | | | INVITE | +---->|------------------------------->| | | [TLS Connection] | Security Exch. | |<------------------------------>| ----------------| | 401 Unauthorized | Phase | |<-------------------------------| | | INVITE | +---->|------------------------------->| | 100 Trying | |<-------------------------------| | 180 Ringing | |<-------------------------------| 9.3. Signaling Exchange Phase The signaling exchange phase is a necessary step to progress towards establishing peering. This phase may incorporate the security exchange phase, but it is not required. This phase follows standard methods described in [2], so the following flow provides an example of this phase, but does not incorporate all possibilities. Kaplan, et al Expires January 14, 2009 [Page 17] Internet-Draft draft-ietf-speermint-flows-03 July 2008 Peer Proxy Peer Proxy | | | [TLS Connection] | +---->|<------------------------------>| | | INVITE | | |------------------------------->| Signaling Exch. | | 100 Trying | -----------------| |<-------------------------------| Phase | | 180 Ringing | | |<-------------------------------| | | 200 OK | | |<-------------------------------| | | ACK | | |------------------------------->| | | BYE | | |<-------------------------------| | | 200 OK | +---->|------------------------------->| | | 9.4. Media Exchange Phase The media exchange phase is negotiated and established during the signaling exchange phase. This phase follows standard methods described in [2], so the following flow provides an example of this phase, but does not incorporate all possibilities. Alice Peer Proxy Peer Proxy Bob +---->|INVITE | | | | |----------->| INVITE | | | | 100 |------------------>| INVITE | | |<-----------| 100 Trying |----------->| Media Exch. | | |<------------------| 100 | ---------------| | | |<-----------| Phase | | | | 180 | | | | 180 Ringing |<-----------| | | 180 |<------------------| 200 | | |<-----------| 200 OK |<-----------| | | 200 |<------------------| | | |<-----------| | | | |ACK | | | +---->|----------->|ACK | | | |------------------>|ACK | | | |----------->| | Both Way RTP Media | | |<===========================================>| Kaplan, et al Expires January 14, 2009 [Page 18] Internet-Draft draft-ietf-speermint-flows-03 July 2008 | | | | | | | BYE | | | BYE |<-----------| | BYE|<------------------| | |<-----------| | | |200 | | | |----------->|200 | | | |------------------>|200 | | | |----------->| 10. Security Considerations The level of security required during the establishment and maintenance of a SIP peering relationship between two 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 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 a VPN), one could argue that basic filtering based on IP address is enough. 11. IANA Considerations N/A 12. Acknowledgments Thanks to Reinaldo Penno for his work as the original author of this document, and to Otmar Lendl for his contributions. 13. References 13.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. Kaplan, et al Expires January 14, 2009 [Page 19] Internet-Draft draft-ietf-speermint-flows-03 July 2008 [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] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [8] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [9] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. 13.2. Informative References [10] Meyer, D., Malas, D., "SPEERMINT Terminology", Internet Draft, draft-ietf-speermint-terminology-16, February 2008. [11] Boulton, C., Rosenberg, J., Camarillo, G., "Best Current Practices for NAT Traversal for SIP", Internet Draft, draft- ietf-sipping-nat-scenarios-08, April 2008. [12] Camarillo, G., Penfield, R., Hawrylyshen, A., "Requirements from SIP (Session Initiation Protocol) Session Border Controller Deployments", Internet Draft, draft-camarillo- sipping-sbc-funcs-06, June 2008. [13] Gurbani, V., Mahy, R., Tate, B., " Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sip-connect- reuse-11, July 2008. Author's Addresses Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan, et al Expires January 14, 2009 [Page 20] Internet-Draft draft-ietf-speermint-flows-03 July 2008 Daryl Malas Level 3 Communications LLC 1025 Eldorado Blvd. Broomfield, CO 80021, USA EMail: daryl.malas@level3.com Sohel Khan, Ph.D. Comcast Cable Communications USA Email: sohel_khan@cable.comcast.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 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. Kaplan, et al Expires January 14, 2009 [Page 21] Internet-Draft draft-ietf-speermint-flows-03 July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan, et al Expires January 14, 2009 [Page 22]