Internet Engineering Task Force                             James M. Polk
Internet Draft                                              Cisco Systems
Expiration: March 17th, 2003
File: draft-polk-ieprep-scenarios-00.txt









                         IEPREP Topology Scenarios

                            September 17th, 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 attempts, without going into too much complexity, to articulate
the likely topological scenarios which should be encountered, thus focused
on by this working group when writing requirements, gap analysis and other
solutions documents.






Polk                      IEPREP Topology Scenarios                 Page 1

Internet Draft       draft-polk-ieprep-scenarios-00.txt    Sept 17th, 2002


Table of Contents

Abstract  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
1.0  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
1.2  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.0  Overview of IEPREP . . . . . . . . . . . . . . . . . . . . . . . .  2
3.0  IEPREP Topologies  . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.1 Topology A û IP in the Middle  . . . . . . . . . . . . . . . . . .  3
 3.2 Topology B û IP at the Start . . . . . . . . . . . . . . . . . . .  4
 3.3 Topology C û IP at the End . . . . . . . . . . . . . . . . . . . .  5
 3.4 Topology D û IP End-to-End . . . . . . . . . . . . . . . . . . . .  5
4.0 Security Considerations . . . . . . . . . . . . . . . . . . . . . .  6
5.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . .  6
6.0 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . .  6
7.0 References  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
8.0 Authors Information . . . . . . . . . . . . . . . . . . . . . . . .  7


1.0     Introduction

This memo attempts, without going into too much complexity, to articulate
the likely topological scenarios which should be encountered, thus focused
on by this working group when writing requirements, gap analysis and other
documents.

There has been much confusion on the IEPREP list as well as within each
meeting (including the interim) as to the topologies IEPREP is referring
to. Hopefully this document will give each reader a reference to which
they can point to and say (with conviction) in scenario A, x happens, or y
is broken; instead of consistently having list and session contributors
have to describe the topology to which they are referring to as well as
their point to be made.

This memo attempts to be agnostic with regard to IP signaling or control
protocols (SIP, MEGACO, etc).


1.2 Motivation

Simply put, to get everyone referencing the same (named) topologies in
order to have useful and less confusing dialog to further this WG's
efforts.


2.0 Overview of IEPREP

IEPREP is an international mechanism for signaling preferential treatments
of communications used by only a select few of our population. These are
authorized individuals trained in the usage of Emergency Preparedness


Polk                      IEPREP Topology Scenarios                 Page 2

Internet Draft       draft-polk-ieprep-scenarios-00.txt    Sept 17th, 2002

Methods and Mechanisms. [1] details the framework of the IEPREP effort,
and several requirements IDs can be found at the IEPREP WG homepage at:
http://www.ietf.org/html.charters/ieprep-charter.html. Further information
regarding the WG efforts should be researched there and the list archives.


3.0 IEPREP Topologies

There are 4 often mentioned, but very little documented topologies
discussed within this WG's work so far. The following subsections will go
through each of the 4 that were first articulated by Scott Bradner in an
analysis he did as a result of a side conversation regarding the SIP
Resource Priority Header ID [2] and its usefulness within the IEPREP
charter.

The 4 topologies are (quickly):

     Topology A û IP in the Middle

     Topology B û IP at the Start

     Topology C û IP at the End

     Topology D û IP End-to-End

Within each topology listed above, and detail in the following sections,
is the question of "where is the authentication/authorization occurring"?
This should add another dimension to Topologies B and C (making a total of
six topologies, but with this first version of this document, explanation
of it is left to within the explanation section for B and C respectively.
As far as topologies A and D, with regard to where authentication/
authorization occurs, it's most likely in the topology A that
authentication/authorization will occur in the Circuit Switched Network
(CSN) on either side the IP core, therefore auth/auth in the IP section of
the network will not (yet) be discussed further. For topology D, auth/auth
can only occur within the IP network.

The following sections detail each of the 4 topologies.


3.1 Topology A û IP in the Middle

Otherwise known as IP Bridging two CSNs. In this topology, a CSN phone of
any type makes a call to another CSN phone with an IP core between the two
CSNs. This topology should behave as the GETS (in the US) or GTPS (in the
UK) service behaves today, any IP section in the call path should be for
transport only, though should convey the appropriate signaling for IEPREP
or ETS behaviors within the packets (defined elsewhere). User
authentication and authorization should occur within the CSN as it occurs
in today's CSN only network. This topology should simplistically look like
this:


Polk                      IEPREP Topology Scenarios                 Page 3

Internet Draft       draft-polk-ieprep-scenarios-00.txt    Sept 17th, 2002



   Circuit                     Internet                     Circuit
   Switched                       or                        Switched
   Network                    IP Segment                    Network
  -----------+              +--------------+              +-----------
             |    +----+    |     IP       |    +----+    |
     CSN     |    |    |    |              |    |    |    |     CSN
    Phone --------| GW |------------------------| GW |-------- Phone
             |    |    |    |              |    |    |    |
             |    +----+    |              |    +----+    |
  -----------+              +--------------+              +---------

              Figure 1. Topology A û IP in the Middle


3.2 Topology B û IP at the Start

This topology has the calling party placing the call from an IP Phone, and
the called party being in the CSN (somewhere).


                Internet                             Circuit
                   or                                Switched
               IP Segment                            Network
          +-------------------+                 +---------------
                              |       +----+    |
              IP              |       |    |    |     CSN
             Phone -------------------| GW |-------- Phone
                              |       |    |    |
                              |       +----+    |
          +-------------------+                 +---------------

              Figure 2. Topology B û IP at the Start


The added dimension is the question of where the authentication/
authorization is done for the IEPREP or ETS service. If it is done within
the CSN, it can only be performed by the caller in a form that the CSN
understands: digits on the keypad of the phone, or speaker recognition
(which isn't currently used in the CSN, but could be). If the caller is
authorized to perform some form of preferential treatment with that call,
the CSN needs a mechanism to convey that authorization back to the
caller's device in such a way that the IP network will understand.









Polk                      IEPREP Topology Scenarios                 Page 4

Internet Draft       draft-polk-ieprep-scenarios-00.txt    Sept 17th, 2002


3.3 Topology C û IP at the End

This topology has the calling party placing the call from an CSN phone
(somewhere), and the called party being in an IP network.


             Circuit                               Internet
             Switched                                 or
             Network                              IP Segment
          +-------------------+                 +---------------
                              |       +----+    |
              CSN             |       |    |    |     IP
             Phone -------------------| GW |-------- Phone
                              |       |    |    |
                              |       +----+    |
          +-------------------+                 +---------------

              Figure 3. Topology C û IP at the End


Authentication/Authorization in topology C should occur within the CSN on
the originating side of the call path. In time, there might be situations
where the CSN is only a transport into the IP network of an IEPREP call,
therefore similar attributes to topology B should occur within C; where
the IP authentication/authorization mechanism must be conveyed to the CSN
Gateway (and on to the calling user) in such a way as to identify that
call on an e2e basis to behave according to the goals set forth by the
IEPREP WG for that call.


3.4 Topology D û IP End-to-End

This topology has no circuit switched sections in the call path.
Therefore, authentication/authorization must occur in IP, and in such a
way to provide the end station enough information (tokens, strings, etc)
to convey an IEPREP desired behavior for that call throughout the IP
network.















Polk                      IEPREP Topology Scenarios                 Page 5

Internet Draft       draft-polk-ieprep-scenarios-00.txt    Sept 17th, 2002



                            Internet
                               or
                           IP Network
            +-----------------------------------------+
            |                                         |
  +---------+                                         +-----------+
  |                                                               |
  |   IP                                                  IP      |
  |  Phone --------------------------------------------- Phone    |
  |                                                               |
  +---------+                                         +-----------+
            |                                         |
            +-----------------------------------------+

              Figure 4. Topology D û IP End to End


4.0 Security Considerations

This document does not suggest anything other than a common naming
convention within IEPREP WG discussions, therefore there should be no
special security considerations


5.0 IANA Considerations

There are no IANA considerations within this document


6.0 Acknowledgements

Scott Bradner for his articulation in a prior discussions outlining these
topologies that are described here


7.0 References

[1] K. Carlberg and I. Brown, "Framework for supporting IEPS in IP
telephony," Internet Draft, Internet Engineering Task Force, Jun 24, 2002.
Work in progress.

[2] J. Polk, H. Schulzrinne, "SIP Resource Priority Header", Internet
Draft, Internet Engineering Task Force, March 2002.  Work in progress.








Polk                      IEPREP Topology Scenarios                 Page 6

Internet Draft       draft-polk-ieprep-scenarios-00.txt    Sept 17th, 2002

8.0 Authors Information

James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA
jmpolk@cisco.com


"Copyright (C) The Internet Society (2002).
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."




The Expiration date for this Internet Draft is:

March 17th, 2003












Polk                      IEPREP Topology Scenarios                 Page 7