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/