< draft-polk-ieprep-scenarios-02.txt		draft-polk-ieprep-scenarios-03.txt >
	Internet Engineering Task Force James M. Polk		A new Request for Comments is now available in online RFC libraries.
	Internet Draft Cisco Systems
	Expiration: June 3rd, 2003
	File: draft-polk-ieprep-scenarios-02.txt
	IEPREP Topology Scenarios
	December 3rd, 2002
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.
	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.
	Abstract
	This memo conveys simplistically the likely topological scenarios that may
	be encountered in reference to IEPREP phone calls. These scenarios should
	be used to focus the IEPREP Working Group during discussions and when
	writing requirements, gap analysis and other solutions documents.
	Table of Contents
	Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
	Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.2 Changes from previous versions . . . . . . . . . . . . . . . . . . 2
	1.3 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . 3
	2.0 IEPREP Topologies . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1 Topology "IP Bridging" . . . . . . . . . . . . . . . . . . . . . . 3
	2.2 Topology "IP at the Start" . . . . . . . . . . . . . . . . . . . . 4
	2.3 Topology "IP at the End" . . . . . . . . . . . . . . . . . . . . . 4
	2.4 Topology "End-to-End IP" . . . . . . . . . . . . . . . . . . . . . 5
	3.0 Security Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	4.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5
	5.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.0 Authors Information . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.0 Introduction
	This memo conveys simplistically the likely topological scenarios that may
	be encountered in reference to IEPREP phone calls. These scenarios should
	be used to focus the IEPREP Working Group during discussions and when
	writing requirements, gap analysis and other solutions documents.
	There has been much confusion on the IEPREP list as well as within each
	meeting about the topologies IEPREP is considering. Hopefully this
	document will give each reader and author a reference set of named
	architectures.
	This memo attempts to be agnostic with regard to IP signaling or control
	protocols (SIP, MEGACO, etc), as well as any underlying QOS mechanisms
	(Diffserv, RSVP, NSIS, etc).
	1.1 Motivation
	Simply put, to get everyone referencing the same (named) topologies in
	order to have useful and less confusing dialog to further this working
	group's efforts.
	1.2 Changes From Previous Versions
	Changes from -00 to -01
	This version greatly reduces the text of the overall document by removing
	all discussion of requirements and authentication & authorization. This is
	not a requirements document (therefore shouldn't state any), and the A&A
	text/discussion for each of the topologies, though necessary within the WG,
	has been moved to another "ieprep-topology-implications" document.
	Changes from -01 to -02
	Cleaned up minor omissions discovered that weren't omitted from the -00 to
	-01 change.
	Took out the paragraph following Figure 2 (section 2.2) referring to where
	ETS aware devices should be.
	1.3 Terms and Definitions
	The following acronyms need to be exploded for clarity:
	CSN = Circuit Switched Network
	GW = Gateway (CSN to IP, or IP to CSN)
	2.0 IEPREP Topologies
	There are 4 often mentioned, but very little documented topologies
	discussed within this WG's efforts so far. The following subsections name
	and describe each of the topologies.
	The 4 topologies are (quickly):
	Topology "IP Bridging"
	Topology "IP at the Start"
	Topology "IP at the End"
	Topology "End-to-End IP"
	2.1 Topology "IP Bridging"
	This topology is sometimes known as "IP in the Middle" of two CSNs. In
	this topology, a CSN phone of any type initiates (dials) a call to another
	CSN phone with an IP core between the two CSNs.
	This topology should simplistically look like this:
	Circuit Internet Circuit
	Switched IP or IP Switched
	Network Ingress IP Segment Egress Network
	-----------+ +--------------+ +-----------
	| +----+ | IP | +----+ |
	CSN | | | | | | | | CSN
	Phone ------->| GW |----------------------->| GW |-------->Phone
	| | | | | | | |
	| +----+ | | +----+ |
	-----------+ +--------------+ +-----------
	Figure 1. Topology "IP Bridging"
	2.2 Topology "IP at the Start"
	This topology has the initiating party placing (dialing) the call from an
	IP Phone (PDA or computer), and the called party residing in the CSN.
	Internet Circuit
	or CSN Switched
	IP Segment Ingress Network
	-------------------+ +---------------
	| +----+ |
	IP | | | | CSN
	Phone ------------------>| GW |--------> Phone
	| | | |
	| +----+ |
	-------------------+ +---------------
	Figure 2. Topology "IP at the Start"
	2.3 Topology "IP at the End"
	This topology has the calling party placing the call from a CSN phone, and
	the called party being in an IP network.
	Circuit Internet
	Switched CSN or
	Network Egress IP Segment
	-------------------+ +---------------
	| +----+ |
	CSN | | | | IP
	Phone ------------------>| GW |--------> Phone
	| | | |
	| +----+ |
	-------------------+ +---------------
	Figure 3. Topology "IP at the End"
	2.4 Topology "End-to-End IP"
	This topology has no circuit switched sections in the call path.
	Internet
	or
	IP Network
	+-----------------------------------------+
	| |
	+---------+ +-----------+
	| |
	| IP IP |
	| Phone --------------------------------------------> Phone |
	| |
	+---------+ +-----------+
	| |
	+-----------------------------------------+
	Figure 4. Topology "End to End IP"
	3.0 Security Considerations
	This document merely suggests a common naming convention within IEPREP WG
	discussions, therefore there are no special security considerations.
	4.0 IANA Considerations
	There are no IANA considerations within this document		RFC 3523
	5.0 Acknowledgements
	To Scott Bradner, Kimberly King and Mike Pierce for their comments and		Title: Internet Emergency Preparedness (IEPREP)
	suggestions		Telephony Topology Terminology
			Author(s): J. Polk
			Status: Informational
			Date: April 2003
			Mailbox: jmpolk@cisco.com
			Pages: 6
			Characters: 10190
			Updates/Obsoletes/SeeAlso: None
	6.0 References		I-D Tag: draft-polk-ieprep-scenarios-03.txt
	none at this moment		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3523.txt
	7.0 Authors Information		This document defines the topology naming conventions that are to be
			used in reference to Internet Emergency Preparedness (IEPREP) phone
			calls. These naming conventions should be used to focus the IEPREP
			Working Group during discussions and when writing requirements, gap
			analysis and other solutions documents.
	James M. Polk		This document is a product of the Internet Emergency Preparedness
	Cisco Systems		Working Group of the IETF.
	2200 East President George Bush Turnpike
	Richardson, Texas 75082 USA
	jmpolk@cisco.com
	"Copyright (C) The Internet Society (2002).		This memo provides information for the Internet community. It does
	All Rights Reserved.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	This document and translations of it may be copied and furnished to		This announcement is sent to the IETF list and the RFC-DIST list.
	others, and derivative works that comment on or otherwise explain it		Requests to be added to or deleted from the IETF distribution list
	or assist in its implementation may be prepared, copied, published and		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	distributed, in whole or in part, without restriction of any kind,		added to or deleted from the RFC-DIST distribution list should
	provided that the above copyright notice and this paragraph are		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of developing
	Internet standards in which case the procedures for copyrights defined
	in the Internet Standards process must be followed, or as required to
	translate it into languages other than English.
	The limited permissions granted above are perpetual and will not be		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	revoked by the Internet Society or its successors or assigns.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and the information contained herein is provided on an		To: rfc-info@RFC-EDITOR.ORG
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		Subject: getting rfcs
	TASK FORCE DISCLAIMS 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."
	The Expiration date for this Internet Draft is:		help: ways_to_get_rfcs
	June 3rd, 2003		Requests for special distribution should be addressed to either the
			author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	237 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/