summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3523.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3523.txt')
-rw-r--r--doc/rfc/rfc3523.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc3523.txt b/doc/rfc/rfc3523.txt
new file mode 100644
index 0000000..87c2c36
--- /dev/null
+++ b/doc/rfc/rfc3523.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group J. Polk
+Request for Comments: 3523 Cisco Systems
+Category: Informational April 2003
+
+
+ Internet Emergency Preparedness (IEPREP)
+ Telephony Topology Terminology
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.2 Terms and Definitions . . . . . . . . . . . . . . . . . . 2
+ 2. IEPREP Topologies. . . . . . . . . . . . . . . . . . . . . . 2
+ 2.1 Topology "IP Bridging" . . . . . . . . . . . . . . . . . 3
+ 2.2 Topology "IP at the Start". . . . . . . . . . . . . . . . 3
+ 2.3 Topology "IP at the End". . . . . . . . . . . . . . . . . 4
+ 2.4 Topology "End-to-End IP". . . . . . . . . . . . . . . . . 4
+ 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 5
+ 8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+Polk Informational [Page 1]
+
+RFC 3523 IEPREP April 2003
+
+
+1. Introduction
+
+ This document defines the topology naming conventions that are to be
+ used in reference to IEPREP phone calls. These naming conventions
+ should be used to focus the IEPREP Working Group (WG) 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
+ Quality of Service (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 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. 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"
+
+
+
+
+
+Polk Informational [Page 2]
+
+RFC 3523 IEPREP April 2003
+
+
+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"
+
+
+
+
+
+
+
+
+
+
+
+
+Polk Informational [Page 3]
+
+RFC 3523 IEPREP April 2003
+
+
+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"
+
+ Although shown as one large IP cloud here, the Internet is composed
+ of a series of loosely connected IP domains. An End-to-End IP call
+ will likely traverse a number of these domains and/or multiple
+ network providers, which may impact the call.
+
+
+
+
+
+
+
+
+
+Polk Informational [Page 4]
+
+RFC 3523 IEPREP April 2003
+
+
+3. Security Considerations
+
+ This document merely suggests a common naming convention within
+ IEPREP WG discussions, therefore there are no special security
+ considerations.
+
+4. IANA Considerations
+
+ There are no IANA considerations within this document.
+
+5. Acknowledgements
+
+ To Scott Bradner, Kimberly King and Mike Pierce for their comments
+ and suggestions.
+
+6. References
+
+ There are no references at the present time.
+
+7. Author's Address
+
+ James M. Polk
+ Cisco Systems
+ 2200 East President George Bush Turnpike
+ Richardson, Texas 75082 USA
+
+ EMail: jmpolk@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk Informational [Page 5]
+
+RFC 3523 IEPREP April 2003
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ 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
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Polk Informational [Page 6]
+