draft-ietf-speermint-architecture-18.txt   draft-ietf-speermint-architecture-19.txt 
SPEERMINT D. Malas, Ed. SPEERMINT D. Malas, Ed.
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Informational J. Livingood, Ed. Intended status: Informational J. Livingood, Ed.
Expires: August 21, 2011 Comcast Expires: August 22, 2011 Comcast
February 17, 2011 February 18, 2011
Session PEERing for Multimedia INTerconnect Architecture Session PEERing for Multimedia INTerconnect Architecture
draft-ietf-speermint-architecture-18 draft-ietf-speermint-architecture-19
Abstract Abstract
This document defines a peering architecture for the Session This document defines a peering architecture for the Session
Initiation Protocol (SIP), its functional components and interfaces. Initiation Protocol (SIP), its functional components and interfaces.
It also describes the components and the steps necessary to establish It also describes the components and the steps necessary to establish
a session between two SIP Service Provider (SSP) peering domains. a session between two SIP Service Provider (SSP) peering domains.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 21, 2011. This Internet-Draft will expire on August 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 31 skipping to change at page 3, line 31
6.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 10 6.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 10
6.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 11 6.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 11
6.1.3. The Signaling Path Border Element (SBE) . . . . . . . 11 6.1.3. The Signaling Path Border Element (SBE) . . . . . . . 11
6.1.3.1. Establishing a Trusted Relationship . . . . . . . 11 6.1.3.1. Establishing a Trusted Relationship . . . . . . . 11
6.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 11 6.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 11
6.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 11 6.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 11
6.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 12 6.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 12
6.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 12 6.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 12
6.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 12 6.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 12
6.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 12 6.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 13
7. Address Space Considerations . . . . . . . . . . . . . . . . . 13 7. Address Space Considerations . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 11, line 43 skipping to change at page 11, line 43
6.1.3.1. Establishing a Trusted Relationship 6.1.3.1. Establishing a Trusted Relationship
Depending on the security needs and trust relationships between SSPs, Depending on the security needs and trust relationships between SSPs,
different security mechanisms can be used to establish SIP calls. different security mechanisms can be used to establish SIP calls.
These are discussed in the following subsections. These are discussed in the following subsections.
6.1.3.2. IPSec 6.1.3.2. IPSec
In certain deployments the use of IPSec between the signaling In certain deployments the use of IPSec between the signaling
functions of the originating and terminating domains can be used as a functions of the originating and terminating domains can be used as a
security mechanism instead of TLS. security mechanism instead of TLS. However, such IPSec use should be
the subject of a future document as additional specification is
necessary to use IPSec properly and effectively.
6.1.3.3. Co-Location 6.1.3.3. Co-Location
In this scenario the SFs are co-located in a physically secure In this scenario the SFs are co-located in a physically secure
location and/or are members of a segregated network. In this case location and/or are members of a segregated network. In this case
messages between the originating and terminating SSPs could be sent messages between the originating and terminating SSPs could be sent
as clear text (unencrypted). However, even in these semi-trusted co- as clear text (unencrypted). However, even in these semi-trusted co-
location facilities, other security or access control mechanisms may location facilities, other security or access control mechanisms may
be appropriate, such as IP access control lists or other mechanisms. be appropriate, such as IP access control lists or other mechanisms.
skipping to change at page 15, line 44 skipping to change at page 16, line 5
Global Crossing Global Crossing
Rochester, NY - USA Rochester, NY - USA
Email: adam.uzelac@globalcrossing.com Email: adam.uzelac@globalcrossing.com
12. Change Log 12. Change Log
NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION.
o 19: Additional change to the IPSec section at Jari Arkko's
request.
o 18: Made several changes based on feedback from Adrian Farrel, o 18: Made several changes based on feedback from Adrian Farrel,
Bert Wijnen, Dan Romascanu, Avshalom Houri, Russ Housley, Sean Bert Wijnen, Dan Romascanu, Avshalom Houri, Russ Housley, Sean
Turner, Tim Polk, and Russ Mundy during IESG review. Turner, Tim Polk, and Russ Mundy during IESG review.
o 17: Misc. updates at the request of Gonzalo, the RAI AD, in order o 17: Misc. updates at the request of Gonzalo, the RAI AD, in order
to clear his review and move to the IESG. This included adding to clear his review and move to the IESG. This included adding
terminology from RFC 5486 and expanding the document name. terminology from RFC 5486 and expanding the document name.
o 16: Yes, one final outdated reference to fix. o 16: Yes, one final outdated reference to fix.
 End of changes. 6 change blocks. 
6 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/