[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET DRAFT                                             P. Tom Taylor
Category: Informational                        Nortel (Northern Telecom)
Title: draft-taylor-ipdc-reqts-00.txt Date: September 1998



      Requirements for A Telephony Gateway Device Control Protocol
                    <draft-taylor-ipdc-reqts-00.txt>


Status of this Memo

   This document is  an  Internet-Draft.   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.''

   To learn the current status of any Internet-Draft, please  check  the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories  on  ftp.is.co.za   (Africa),   nic.nordu.net   (Europe),
   munnari.oz.au   (Pacific  Rim),  ftp.ietf.org  (US  East  Coast),  or
   ftp.isi.edu (US West Coast).

Abstract

   This document describes the requirements for a protocol to control  a
   device  which  supports  telephone  lines  or  trunks on one side and
   packet network ports on the other.   The  primary  functions  of  the
   device  are  to  make,  modify,  and  break  media stream connections
   between  these  edge-points,  to  perform  operations  on  the  media
   streams,  and  to  detect  and report specific events associated with
   those streams or the edge-points. This device may also terminate call
   signalling  which  it  processes  itself  and/or passes to the device
   which controls it.  Using the terminology provided by  Cuervo  et  al
   [1],  the device just described is a Media Gateway, and is controlled
   by a Media Gateway Controller.

   The requirements for the protocol  separate  into  two  major  parts:
   operational   and   functional.   The  operational  requirements  are
   concerned with reliability and security of control messaging, control
   session  startup  and takedown, handling of control session failures,
   and control system performance.  The  functional  requirements  cover
   connection   control,   media  processing,  event  notification,  and



Taylor                     expires March 1999                   [Page 1]


INTERNET DRAFT        Device Control Requirements         September 1998


   resource status tracking.  They may also include signalling  backhaul
   from the Media Gateway to the Media Gateway Controller.

   The protocol should extend to the control of  devices  which  contain
   telephony edge-points only (such as digital cross-connects) or packet
   network ports only (such as transcoders or announcement servers).


Table Of Contents

1.0  Introduction
     1.1  Terminology
     1.2  Definitions
     1.3  Application Examples
          1.3.1  Network Access Server
          1.3.2  Internet Telephony Media Gateway
          1.3.3  Continuity Test
          1.3.4  Interactive Voice Response Unit
          1.3.5  Digital Cross-Connect
     1.4  Network Context
          1.4.1  Distribution of Signalling and Control Functions
               1.4.1.1  Device Control and Tone-Based Signalling Schemes
               1.4.1.2  Transparent Carriage of Signalling Protocol Data
          1.4.2  Possible Control Arrangements

2.0  Operational Requirements
     2.1  Reliability
     2.2  Failure Recovery
     2.3  Startup and Takedown
     2.4  Control Security
     2.5  Performance

3.0  Functional Requirements
     3.1  Connection Control
     3.2  Tones and Announcements
     3.3  Event Notification and Scripts
     3.4  Tone Signalling
     3.5  Signalling Backhaul
     3.6  Resource Status Tracking
     3.7  Other
          3.6.1  Vendor Extensibility
          3.6.2  Architectural Flexibility

4.0  Security Aspects

5.0  References

6.0  Acknowledgements



Taylor                     expires March 1999                   [Page 2]


INTERNET DRAFT        Device Control Requirements         September 1998


7.0  Author's Address



1.0   Introduction

   A broadening  class  of  network  configurations  exists  within  the
   internet,  such  that  one  device which switches and processes media
   streams is controlled  by  another  which  handles  call  signalling.
   Cuervo et al [1] give several examples of such devices sitting on the
   boundary between the telephone and packet data networks.  One is  the
   Network Access Server, which terminates telephony network connections
   on modems and establishes connections through the packet  network  to
   serve  them.   Another  is  the  media handling part of Voice over IP
   gateways, where this  part  is  packaged  separately  from  the  call
   processing part.

   Cuervo et al apply the term "Media Gateway"  to  the  function  which
   processes  and switches media streams, and "Media Gateway Controller"
   to the function which controls the operation  of  the  Media  Gateway
   function.   Where these functions are packaged in separate devices, a
   protocol is needed to carry commands,  responses,  and  notifications
   between them.

   The primary intent of this document is to describe  the  requirements
   which  apply  to  a  media gateway control protocol.  However, such a
   protocol also has application to devices which  lie  entirely  within
   the  packet  network rather than on its boundary, and even to devices
   which serve only telephone network terminations, provided  that  they
   can  be controlled through the IP network.  A first broad requirement
   is therefore that the scope of application  of  the  protocol  should
   include such devices.


1.1   Terminology

   In this document, the  key  words  "MUST",  "MUST  NOT",  "REQUIRED",
   "SHALL",  "SHALL  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
   indicate requirement levels for the device control protocol.


1.2   Definitions

   Edge-Point
      A general term for a point on the edge of a  given  Media  Gateway
      where a media stream enters and/or leaves the device.  Physically,
      edge-points consist of line or trunk appearances on the  telephone



Taylor                     expires March 1999                   [Page 3]


INTERNET DRAFT        Device Control Requirements         September 1998


      network  side,  or  one  or  a  pair of RTP/RTCP port pairs on the
      packet side, depending on whether the media stream is uni- or  bi-
      directional.  [On the packet side, should this be broader?]

   Call Signalling
      A series of messages  between  two  devices  conveying  an  user's
      request  for  service,  possibly requesting more information about
      that request, and coordinating the actions of  the  devices  which
      provide that service.

   Device Control
      Messages between a Media  Gateway  Controller  ("controller",  for
      short)  and a Media Gateway causing the latter to perform specific
      actions required to satisfy an user's request for service.

   Media Stream
      A flow of information which appears in the telephony network as an
      analogue  signal,  typically  digitally encoded, and in the packet
      network as a stream of packets, typically encapsulated by RTP  [3]
      or  PPP  [4].  In this document, the term "media stream" implies a
      two-way flow of information.  The terms  "incoming  media  stream"
      and  "outgoing  media  stream"  imply  one-way flows relative to a
      specified edge-point of a device.


1.3     Application Examples

   This section gives a series of examples of potential applications  of
   Media  Gateways,  in order to motivate the statements of requirements
   in sections 2 and 3 of this document.  In this section  only,  it  is
   generally assumed that all call signalling and control processing are
   done on devices other than the Media Gateway device, except for  DTMF
   signalling  for  specific  purposes  (authorization  code  in section
   1.3.2, Interactive Voice Response Unit controls  in  section  1.3.4).
   This assumption is relaxed in section 1.4.1.


1.3.1   Network Access Server

   A Network Access Server (NAS) is a Media Gateway  connecting  between
   telephony  bearers  carrying modem signals on one side and the packet
   network on the other.  All of its services are call-associated, where
   the  call  is between an user device within the telephone network and
   the call processing application associated with the  NAS  controller.
   Calls may be incoming or outgoing relative to the telephone network.

   For an incoming call, the typical exchanges  of  information  between
   the Media Gateway and the controller would be as follows:



Taylor                     expires March 1999                   [Page 4]


INTERNET DRAFT        Device Control Requirements         September 1998


   a)    A control request to the  NAS  causes  it  to  assign  a  modem
   termination  to  the  call  and connect it to the designated incoming
   trunk or line.  It may be necessary for the controller  to  tell  the
   NAS  what codec is in use on the telephony side of the call.  The NAS
   must tell the controller if the request fails.

   b1)   If the NAS  is  responsible  for  obtaining  authorization  and
   routing  information (e.g. from a RADIUS server) it must be given the
   calling and called  number  information  provided  by  the  telephone
   network.   The  NAS  must  tell  the controller if the RADIUS request
   fails.

   b2)   Alternatively, if some other device obtains  the  authorization
   and  routing  information,  the  NAS  must be told what IP address to
   assign to the caller's device, to what IP address the  caller's  data
   should  be sent, and any other policy information governing the NAS's
   transformation of the user's data into packets.

   c)    The NAS must  tell  the  controller  when  the  user  completes
   his/her data session.  (It is assumed that the NAS then automatically
   frees the modem and clears the connection between the line or  trunk.
   Otherwise  another  message  is needed from the controller to trigger
   this action.)

   A variant on the incoming call sequence may  require  termination  of
   the  initial  call  after  the first exchange with the RADIUS server,
   followed by a call back to  the  caller's  modem  using  a  telephone
   number  provided  by RADIUS.  If this is the case, and the NAS is the
   device which communicated with the RADIUS server,  the  NAS  must  so
   inform  the  controller.  It may or may not be necessary to clear the
   existing modem connection, depending on whether  the  incoming  trunk
   can be reused for the outgoing call.

   An outgoing call is  triggered  by  the  establishment  of  a  packet
   connection (PPP, L2TP) from the calling host to the NAS.  The typical
   exchanges of information in this case are as follows:

   a)    The NAS notifies the controller that a call  to  the  telephone
   network  is required and provides the called party's telephone number
   to the controller.

   b)    The controller assigns the outgoing line or trunk, or asks  the
   NAS  to  select  a  free  trunk from a specified group; whichever end
   makes the selection must inform the other.

   c1)   The controller establishes the call and notifies the  NAS  when
   the connection is complete.




Taylor                     expires March 1999                   [Page 5]


INTERNET DRAFT        Device Control Requirements         September 1998


   c2)   Alternatively the controller asks the NAS  to  notify  it  when
   modem tone is detected on the selected line or trunk.

   d)    The session ends in the same way as an incoming call.

   An important variant on  this  procedure  involves  multiple  bearers
   associated  with  the same call.  A procedure such as BONDING is used
   to establish the association.  The NAS  must  inform  the  controller
   that  the  various connections are correlated [or vice versa -- check
   details].


1.3.2   Internet Telephony Media Gateway

   The Internet Telephony Media Gateway  could  be  an  access  gateway,
   terminating  one  or more user lines directly, or a trunking gateway,
   terminating trunks from a  switch  on  the  telephone  network  side.
   Requirements  for  device  control will be similar in nature for both
   applications, except that the access gateway  must  deal  with  line-
   associated  signalling  and  supervision.   This  is ignored here for
   simplicity, but illustrated in section 1.4.1.

   The following exchanges of information  are  necessary  to  handle  a
   voice call incoming from the telephone network:

   a)    The controller may  tell  the  Media  Gateway  to  reserve  the
   incoming trunk or line so that no other call can claim it.

   b)    The controller may either allocate  ports  for  a  two-way  RTP
   connection  through  the packet network and tell the Media Gateway to
   reserve them, or ask the Media Gateway to allocate ports  and  report
   back.

   c)    The controller tells the Media Gateway to apply  audible  ring-
   back tone back toward the caller.

   d)    In preparation for final cut-through, which must be done within
   40  milliseconds [check this] of the controller's receipt of a signal
   indicating that the called party has answered to  avoid  clipping  of
   the  called  party's first words, the controller also tells the Media
   Gateway to set up a connection between the line or  trunk  appearance
   and  the  RTP  session,  but not to enable the transfer of content in
   either direction until further notice.

   The connection has a number of attributes:
    -- codec in use on the telephone network side of the connection  (if
       not already known from configuration data)
    -- codec to be used on the packet network side of the connection



Taylor                     expires March 1999                   [Page 6]


INTERNET DRAFT        Device Control Requirements         September 1998


    -- whether echo cancellation is to be applied
    -- loss padding to be applied in each direction
    -- method to be used to request transport QOS.

   The user may also have requested confidentiality  service.   In  that
   case,  further  attributes  must  be  passed  to  the  Media  Gateway
   describing the encryption to be performed on the packet stream.

   e)    The  controller  tells  the  Media  Gateway  to  stop  applying
   ringback tone and to complete the two-way connection between the line
   or trunk and the RTP session.

   f)    When the call ends, the controller tells the Media  Gateway  to
   break the connection and free the resources assigned to it.

   g)    The Media Gateway may report QOS statistics derived  from  RTCP
   [3]  reports  to  the  controller,  either  at the end of the call or
   periodically during the call.

   The information exchanges  for  a  call  which  is  outgoing  to  the
   telephone  network  are  very  similar to those for an incoming call.
   Ringback tone will not be applied to the outgoing  telephone  network
   connection,  but  if  the  Media  Gateway  is  an access gateway, the
   controller will direct it to apply ringing to the called line.

   If an incoming call fails to complete  successfully,  the  controller
   may  direct  the  Media  Gateway  to  connect the line or trunk to an
   announcement or to apply  a  busy  or  other  tone  to  it.   If  the
   announcement is to come from a separate announcement server device, a
   one-way incoming RTP connection will be required to  carry  it.   The
   controller  must direct the Media Gateway to release the outgoing RTP
   session ports reserved for the original call and to  make  a  one-way
   connection from the incoming RTP port to the line or trunk.  When the
   user ends the call, the controller must tell  the  Media  Gateway  to
   release all connections and resources as before.

   At  times  it  will  be  necessary  to  preserve  a  connection   but
   temporarily  terminate the transfer of information across it (as with
   call hold service).  Typically this will be followed by the making of
   a  second  connection involving the same Media Gateway edge-point (as
   in consultation hold service or operator handling of  a  call).   The
   edge-point  concerned  may  be either on the telephone network or the
   packet network side of the Media Gateway.

   Another possibility is that the Media Gateway contains  a  conference
   bridge.   The  controller  may  direct  that  the  Media Gateway make
   connections from different telephone network or packet network  edge-
   points on the Media Gateway to specific ports on this bridge.



Taylor                     expires March 1999                   [Page 7]


INTERNET DRAFT        Device Control Requirements         September 1998


   The final possibility considered in this section is  the  case  where
   the  Media Gateway must prompt an user to enter an authorization code
   before continuing with an incoming  call,  must  collect  the  digits
   entered  by  the user, and must report the results to the controller.
   In detail, a variety of sequences of  information  exchanges  may  be
   used to achieve this, but here is a typical example:

   a)    The controller tells the Media Gateway to execute the following
   sequence of actions (i.e. script):

      i)   listen for DTMF signalling on the incoming line or trunk

      ii)  apply a prompt tone requesting the input of the authorization
      code

      iii) collect digits until the earlier of two events occurs:
         -- all N required digits have been entered, where N is given by
            the controller, or
         -- digit  collection  times  out,  with  timing  given  by  the
            controller.

      iv)  report either the digits collected or the timeout failure.

   b)    The Media Gateway makes its report.


1.3.3   Continuity Test

   An SS7-signalled call, whether it  involves  a  NAS  or  an  Internet
   Telephony  Media  Gateway,  will  frequently  begin with a request to
   check the continuity  of  the  media  connection  between  the  Media
   Gateway  and  the upstream bearer path.  There are two possibilities:
   that the Media Gateway  runs  the  test,  or  that  it  provides  the
   loopback.

   In the first case, the following sequence  of  information  exchanges
   occurs:

   a)    The controller specifies a series of actions as follows:

      i)   It specifies a edge-point, representing  the  termination  of
      the network connection to be tested on the Media Gateway.

      ii)  It requests that continuity  test  tone  be  applied  to  the
      indicated  edge-point  in  the  outgoing direction for a specified
      duration.

      iii) It requests that the Media Gateway listen for continuity test



Taylor                     expires March 1999                   [Page 8]


INTERNET DRAFT        Device Control Requirements         September 1998


      tone  incoming  on  the  given  edge-point,  again for a specified
      duration.

      iv)  It requests that the Media  Gateway  report  whether  it  has
      detected incoming continuity test tone or not within the specified
      time period, then terminate the test.

   b)    The Media Gateway reports the result of the test as requested.

   At the  other  end  of  the  connection,  the  following  information
   exchanges take place:

   a)    The controller requests that the Media Gateway  place  a  given
   edge-point into loopback state.

   b)    Subsequently, the controller requests that  the  Media  Gateway
   disconnect the two sides of the edge-point from each other.


1.3.4   Interactive Voice Response Unit

   A Media Gateway associated with an Interactive  Voice  Response  Unit
   plays   announcements  and  tones  to  the  user,  listens  for  DTMF
   signalling, and either reports detected signalling to the  controller
   or  takes  subsequent  actions  based  on  a  script  provided by the
   controller.  To this point, the operation of  the  Interactive  Voice
   Response  Unit  involves  no  new  information exchanges beyond those
   already suggested in section 1.3.2, except that the  scripts  may  be
   more elaborate.

   The new aspect is the  recording  and  playback  of  messages.   This
   requires   the  media  handling  gateway  to  create  uni-directional
   connections between the edge-point on the user side and the recording
   or playback unit respectively.

   It is also possible that the Media Gateway will be told to listen for
   silence during recording, time out after a certain duration, and take
   down the connection.

   A complete  script  will  require  more  specialized  device  control
   actions:  for  skipping  back  through  a  given  message  or between
   messages, for example.  Because of this, requirements for  the  media
   handling  part  of an Interactive Voice Response Unit will be [unless
   decided otherwise] specified in a separate document.


1.3.5   Digital Cross-Connect




Taylor                     expires March 1999                   [Page 9]


INTERNET DRAFT        Device Control Requirements         September 1998


   A digital cross-connect operates only on  digital  channels,  not  on
   packet  streams.   The basic information exchange with the controller
   is the latter's request to connect a  specified  channel  to  another
   specified  channel, or to break a connection.  Additional information
   may be specified when a connection is made, governing the  processing
   of  the digital stream running through it.  Detailed requirements for
   this application are for further study.


1.4     Network Context

   This section considers aspects of the architecture of the  controller
   and  the  Media  Gateway  which lead to the recognition of additional
   requirements for device control.


1.4.1   Distribution of Signalling and Control Functions

   The basic hypothesis of this document is that at least  some  of  the
   Media Gateway Control function required to handle a call resides on a
   physical device which is different from the  one  housing  the  Media
   Gateway  function.   This  leaves  room  for  a  number  of different
   possible arrangements for routing and processing of the various  call
   signalling  protocols  which may be in use in a given network.  There
   are four basic possibilities, where "incoming'  means  the  direction
   from  which the call was initiated and "outgoing" is the direction to
   which it is propagated:

   (i)   The incoming-side call signalling is  processed  at  the  Media
   Gateway  device, while the outgoing-side call signalling is processed
   at the controller.

   (ii)   The  incoming-side  call  signalling  is  processed   at   the
   controller,  while  the outgoing-side call signalling is processed at
   the Media Gateway device.

   (iii) Call signalling for both sides is processed at the  controller.
   One  variant  on this case is that call signalling for either side is
   tunneled through the Media Gateway device to/from the controller,  so
   that the latter is its logical endpoint.

   (iv)  Call signalling for  both  sides  is  processed  at  the  Media
   Gateway  device,  but  the  controller  must  be  involved because it
   contains the service  control  logic  or  owns  the  Media  Gateway's
   resources.

   The application descriptions in section 1.3 assumed case (iii).




Taylor                     expires March 1999                  [Page 10]


INTERNET DRAFT        Device Control Requirements         September 1998


   Cases (i) and (ii) require the operation of one  or  more  signalling
   protocols  between the controller and the Media Gateway device.   The
   choice of which protocols to use for which combinations  of  external
   signalling  protocols  is  in  general  a  matter for call signalling
   experts, and is beyond the scope of device control.  However,  device
   control  can  reasonably  encompass  the  special  case of tone-based
   signalling.  Furthermore, it may be desirable to provide a  mechanism
   for  the  transparent  transfer  of  signalling  information within a
   device control session.

   The detailed requirements imposed by case (iv) require further study.
   They   may   be   implementation-specific   and  not  susceptible  to
   standardization.

1.4.1.1  Device Control and Tone-Based Signalling Schemes

   The operation of tone-based signalling schemes can  be  viewed  as  a
   candidate  for  inclusion  in  a device control protocol both because
   analogue signalling is inseparable from the lines and trunks on which
   it  appears,  and  because  of  the  relatively limited scope of such
   schemes.  Note that tone-based signalling (such as DTMF for lines, MF
   or   R2   for   trunks)  relies  both  on  tones  themselves  and  on
   "supervision" such as  off-hook  and  on-hook  for  lines,  or  wink,
   seizure, and release for trunks, which are signalled by other means.

   The details of such signalling vary from country to country and  over
   different  trunk  and  line types within a country.  Because of this,
   the detailed processing of signalling and supervision is  beyond  the
   scope  of  the requirements provided in this document.  Nevertheless,
   certain basic concepts, such  as  off-hook/seizure,  on-hook/release,
   and  the individual digits, are sufficiently common to all tone-based
   signalling schemes that their representation within a device  control
   protocol could be standardized.

   Looking at  the  matter  another  way,  it  should  be  possible  for
   individual  implementations  of the device control protocol to extend
   this signalling representation scheme to cover the additional  events
   conveyed by specific signalling schemes.

   Now,  assuming  that  the  device  control   protocol   meets   these
   requirements  for  the representation of signalling events, what uses
   of these representations should the protocol allow?   There  are  two
   possibilities,  depending on whether the Media Gateway acts merely as
   a sender and receiver of signals  (i.e.  a  tunnel  for  them,  as  a
   variant  of  case  (iii) in the section 1.4.1), or is also capable of
   taking actions based upon them.

   In  the  first  case,  the  protocol  must  support  three  types  of



Taylor                     expires March 1999                  [Page 11]


INTERNET DRAFT        Device Control Requirements         September 1998


   signalling related messages:
    -- requests from the controller to turn  monitoring  for  signalling
       events on and off,
    -- requests from the controller for specific signalling events to be
       generated, and
    -- messages from the media handling gateway reporting the  detection
       of specific signalling events.

   Because signalling events tend to  happen  in  batches  (particularly
   when  numbers  are  being  passed),  the  protocol should provide for
   efficient handling of batched events.  For incoming signalling,  this
   implies  the  use  of  mechanisms  such  as expected digit counts and
   timeouts.

   If the Media Gateway can  act  on  detected  signalling  events,  the
   possibility  arises  that  it  can be programmed to do so without the
   need  for  intervention  from  the  controller.   This   amounts   to
   processing  of  the  signalling,  and  thus places us into any one of
   cases (i), (ii), or (iv) of section 1.4.1, so that  we  cannot  state
   any specific new requirements on the device control protocol proper.

   The complexity of telephone network  numbering  plans  introduces  an
   intermediate  possibility:  that the Media Gateway may be programmed,
   but the program for a given line or trunk must be updated as the call
   proceeds  to  take  account  of  the  information  the controller has
   already received.  Two basic mechanisms  for  this  purpose  come  to
   mind:  the  device  control  message  may  itself  contain a program,
   written in a pre-defined scripting  language,  or  alternatively  the
   device  control message may invoke and provide parameters for a named
   script or applet.  The device control protocol should provide support
   for at least one of these mechanisms.

1.4.1.2  Transparent Carriage Of Signalling Protocol Data Units

   Under certain circumstances it may be desirable to  carry  unmodified
   signalling  between  the controller and the Media Gateway; this could
   be in either direction.  One example  of  this  is  where  the  Media
   Gateway  can  process  Q.931 (ISDN signalling), but is also presented
   with QSIG signalling from a PBX which the network operator is willing
   to  transport  transparently  to  the  far end.  Another more dubious
   example is where the call signalling is being  tunneled  through  the
   Media Gateway to/from the controller.

   As a general mechanism to support such operations, the device control
   protocol  may  be  required  to  support  the  transfer of signalling
   protocol data units as opaque data, possibly labelled by  a  protocol
   discriminator.   [This  requirement  may be more properly assessed by
   the signalling transport working group.]



Taylor                     expires March 1999                  [Page 12]


INTERNET DRAFT        Device Control Requirements         September 1998


1.4.2   Possible Control Arrangements

   This section is concerned with the possible degrees of redundancy  at
   either  end  of  the  device control session, and their impact on the
   requirements for recovery from failures.

   Control  redundancy  is  commonly  characterized  in   terms   of   a
   temperature  metaphor,  as  if  controllers  were  engines.  In these
   terms, one can have:

   a)    No alternate controller.  If the controller fails, it may  need
   to  retrieve  current  state  from each device under its control upon
   recovery, or it may  have  to  reset  those  devices.   (It  is  also
   possible that at least some state was saved in persistent memory from
   which it can be retrieved without going to the controlled devices.)

   b)    Cold standby, implying that the  alternate  controller  has  no
   knowledge  of  current  state  and  may  have to retrieve it from the
   controlled devices or reset them before taking over.

   c)    Warm standby, implying that the alternate controller always has
   some  knowledge  of current state.  It may either retrieve additional
   state from the controlled  devices  or  invoke  a  partial  reset  in
   specific cases where recovery is impossible.

   d)    Hot standby, implying that the alternate  controller  has  full
   knowledge of current state and can take over without loss of service.

   These different cases suggest a number of requirements on the  device
   control  protocol relating to resets and querying of existing states,
   which are spelled out in detail in section 2.2.   The  one  point  to
   consider   here   is  the  impact  of  such  operations  on  protocol
   performance.

   The first potential problem is a fairly obvious  one,  that  recovery
   may  be  delayed by the sheer volume of messaging required to achieve
   it.  This can be mitigated by careful design of the recovery process,
   to  ensure that the most critical elements get highest priority.  The
   requirement on  the  device  control  protocol  will  be  to  support
   subdivision of the recovery process into the necessary steps.

   The second potential problem is that of  message  fragmentation  when
   large  volumes  of information are passed at once.  If UDP is used as
   the transport protocol, the  device  control  protocol  may  have  to
   support  either end-to-end negotiation of maximum application message
   length, or recovery from message segmentation.





Taylor                     expires March 1999                  [Page 13]


INTERNET DRAFT        Device Control Requirements         September 1998


2.0   Operational Requirements

   This section is concerned with requirements  on  the  design  of  the
   protocol independently of the content to be carried.

2.1     Reliability

   R2.1.1 Transport level reliability: device control messages  MUST  be
   delivered reliably, in the order in which they were sent.

   R2.1.2 Presentation level reliability: the  device  control  protocol
   MUST provide mechanisms to ensure that the originator of a message is
   made aware when that message is rejected or  not  understood  by  the
   receiving entity.

   R2.1.3 Application level reliability:  the  device  control  protocol
   MUST  provide  the means for the originator of a message to determine
   if the recipient of that message failed to process it.


2.2     Failure Recovery

   R2.2.1 The device control protocol MUST provide the means  to  detect
   failure  of  the  control  session within a locally-configurable time
   period (of the order of seconds).

   R2.2.2 The device control protocol MUST  provide  the  means  for  an
   alternative  controller  instance  to  take  over  control of a Media
   Gateway when a control session failure is detected.

   R2.2.3 The device control protocol  MUST  provide  the  means  for  a
   controller  to  negotiate handoff of control of a given Media Gateway
   to another controller.

   R2.2.4 The device control protocol  MUST  provide  the  means  for  a
   controller  to  retrieve  in  controlled  fashion  the details on all
   persistent processes (such as connections and  running  scripts)  and
   all resource reservations currently active in a Media Gateway.

   R2.2.5 The device control protocol SHOULD provide  the  means  for  a
   controller  to  request  that a Media Gateway release all connections
   and resources and restore default initial conditions.  Comment:  this
   is  obviously  a  mechanism  of  last resort for recovery of stranded
   resources.

   R2.2.6 It is DESIRABLE that the device  control  protocol  allow  the
   controller  (i)  to  associate a session identifier with each command
   which assigns resources and creates persistent processes in the Media



Taylor                     expires March 1999                  [Page 14]


INTERNET DRAFT        Device Control Requirements         September 1998


   Gateway,  and  (ii) to release all resources and processes associated
   with a  given  session  identifier,  without  having  to  list  these
   resources  explicitly.  Justification: if an alternate controller can
   retrieve from another source a mapping between the  call  identifiers
   used  in  signalling  and the session identifiers potentially used in
   device control, then when a given call is cleared the controller  can
   release the associated resources without knowing what they are.  This
   reduces  the  urgency  for  the  controller  to  use  the   retrieval
   mechanisms postulated in R2.2.3.

   R2.2.7 The device control protocol  MUST  provide  the  means  for  a
   controller  to  temporarily  reduce the rate of message generation at
   the Media Gateway, to allow the controller to recover from overload.


2.3     Startup and Takedown

   R2.3.1 The device control protocol MUST allow either  the  controller
   or the Media Gateway to initiate control session startup.

   R2.3.2 The device control protocol MUST provide for  the  negotiation
   of protocol version as part of control session startup.

   R2.3.3 The  device  control  protocol  SHOULD  provide  a  means  for
   negotiating  the  support  of optional or vendor-specific portions of
   the protocol.

   R2.3.4 The device control protocol MUST allow graceful termination of
   a control session.


2.4     Control Security

   Control sessions are often run over physically separate links.   When
   they  are  not,  the  primary threats are impersonation and denial of
   service  attacks.   Control  sessions  will  typically  run  directly
   between  the controller and the Media Gateway, without an intervening
   proxy.  This leads to the following requirements.

   R2.4.1 The device control protocol MUST provide for authentication of
   the originator of each message.

   R2.4.2 The device control protocol MUST contain provisions to prevent
   denial of service attacks from being effective.


2.5     Performance




Taylor                     expires March 1999                  [Page 15]


INTERNET DRAFT        Device Control Requirements         September 1998


   The key  dimensions  of   device  control  protocol  performance  are
   response  time and scalability.  Response time requirements depend on
   the application; they are more stringent for a VoIP gateway than  for
   other  applications.   Response times for VoIP gateways MUST be rapid
   (of the order of tens of milliseconds) to conform to the requirements
   of  the  telephone  network.   In  particular, connection setup for a
   voice path MUST be rapid following called user answer,  so  that  the
   initial  portion  of  the  called  user's  greeting  is  not clipped.
   "Response time" here refers to the sum of times  taken  to  formulate
   the  command  message  at  the  controller,  transmit it to the Media
   Gateway, and process and execute it within the Media Gateway.

   R2.5.1 The design of the device control protocol  MUST  be  aimed  at
   minimizing  response  time as defined in the preceding paragraph, for
   time-critical device control operations.

   R2.5.2 The design of the  device  control  protocol  MUST  allow  one
   controller  to  control  tens of thousands of Media Gateways, and one
   Media Gateway to support thousands of edge-points.



3.0 Functional Requirements

   This section is concerned with requirements  on  the  design  of  the
   device  control  protocol related to its applications and the content
   they imply.

3.1     Connection Control

   R3.1.1 The device control protocol MUST support requests  to  create,
   modify, and delete media stream connections between:
    * an edge-point and another edge-point on the same device
    * a line or trunk and a data modem
    * a line or trunk and a FAX modem
    * an edge-point and the port of a conference bridge
    * an edge-point and an  internal  sink  (e.g.  recorder)  for  media
      content
    * [what else?].

   R3.1.2 Extensibility to arbitrary resource types:  The device control
   protocol  SHOULD  support  requests  to  create,  modify,  and delete
   connections between edge-points and arbitrary named  resources  where
   the  assumption  is  that the controller and Media Gateway understand
   what the names "mean".

   R3.1.3 The device control protocol MUST support specification of  the
   following  attributes  of  a  connection either when creating or when



Taylor                     expires March 1999                  [Page 16]


INTERNET DRAFT        Device Control Requirements         September 1998


   modifying a connection:
    * directionality: no media flow, one way in a  specified  direction,
      or two ways
    * whether echo cancellation is to be applied
    * loss padding to be applied on the telephony side of a connection
    * coding and compression algorithms to be applied  in each direction
      of flow
    * whether the media stream should  be  encrypted,  and  if  so,  the
      parameters to be used to accomplish encryption and decryption
    * the method by which transport QOS is  to  be  requested  from  the
      packet network
    * [what else?].

   R3.1.4 Where connection to a data  modem  is  requested,  the  device
   control  protocol  MUST support the carriage of the parameters needed
   for the NAS to complete the connection through  the  packet  network,
   specifically including:
    * called number
    * calling number.

   R3.1.5 The device control protocol SHOULD support a request from  the
   Media  Gateway  to  the  controller  to  make  a  call to a specified
   telephone number.

   R3.1.6 The device control protocol MUST support  responses  from  the
   Media  Gateway  indicating the fact and cause of failure to execute a
   request to create, modify, or delete a connection.

   R3.1.7 The device control protocol SHOULD support the ability to have
   the  Media  Gateway choose and report back the identity of a specific
   edge-point to be used for a connection, within  constraints  provided
   by  the  controller.  Examples of this are selection of an idle trunk
   from a named trunk group, or selection of one or  two  free  RTP/RTCP
   port   pairs   depending   on  the  required  directionality  of  the
   connection.

   R3.1.8 The device control protocol  MUST  support  the  creation  and
   deletion  of  loopback  connections  at  specified  edge-points.   To
   support testing  and  debugging  of  device  operations,  the  device
   control protocol SHOULD also support the creation of loopbacks at one
   edge-point back through the Media Gateway towards another  edge-point
   to which it is connected.

   R3.1.9 The device control protocol  MUST  support  the  retrieval  of
   statistics  indicating  the  quality  of  service received on a given
   packet connection.





Taylor                     expires March 1999                  [Page 17]


INTERNET DRAFT        Device Control Requirements         September 1998


3.2     Tones and Announcements

   R3.2.1 The device control protocol  MUST  support  requests  for  the
   Media  Gateway  to  play  out  and to stop playing out to a specified
   edge-point one or a sequence of named tones and/or announcements.

   R3.2.2 For each tone  or  announcement  to  be  played,  it  MUST  be
   possible   to  specify  the  maximum  amount  of  time  the  tone  or
   announcement is to be played out or, for announcements  specifically,
   how  often  the  announcement should be repeated before discontinuing
   it.

   R3.2.3 The device control protocol MUST support a  mechanism  whereby
   it  is  possible  to associate the commencement and/or termination of
   the playout of specific tones or announcements with  specific  events
   involving  the  endpoint.   This  is  a  specific case of the general
   scripting capability called for requirement R3.3.2.

   R3.2.4 It is DESIRABLE that the device control protocol be capable of
   configuring tone specifications consisting of the following aspects:
    * tone name
    * number of segments
    * for each segment: whether it consists of silence or tone;  if  the
      latter, what frequency or frequencies to use,  at  what  loudness
      level; the segment duration.


3.3     Event Notification and Scripts

   See the final paragraphs of section 1.4.1.1  for  background  on  the
   scripting requirements given here.

   R3.3.1 The device control protocol  MUST  support  requests  for  the
   Media  Gateway  to  start  and  stop  monitoring  for specific events
   observed at an edge-point.   Many  of  the  events  of  interest  are
   covered  under  tone signalling, in the next section.  However, there
   is a specific requirement to detect and report on:
    * modem tone
    * FAX tone
    * various test  tones,  including  continuity  test  [with  national
      variations]
    * busy tone [with national variations]
    * reorder tone [with national variations]
    * [what else?].

   R3.3.2 The device control protocol MUST provide a  mechanism  whereby
   the  controller  can specify mixed sequences of events to be detected
   and actions to be taken (scripting capability).  It MUST be  possible



Taylor                     expires March 1999                  [Page 18]


INTERNET DRAFT        Device Control Requirements         September 1998


   to specify the following within these sequences:
    * conditional subsequences, to be executed only if specified  events
      occur
    * repeated subsequences (loops), where the loop is terminated  by  a
      specified event
    * conditions  under  which  the  entire  script   is   deactivated,
      regardless of  which  specific  step  in  the script is currently
      being executed.  For example, a  script  applied  in  association
      with a connection  between  two  edge-points  may  be  required
      to  deactivate when the connection is deleted.

   R3.3.3  The  device  control  protocol  MUST  provide  the  means  to
   simultaneously  create  or modify a connection and invoke a script on
   or request a report from either or both edge-points involved  in  the
   connection.

   R3.3.4 The device control protocol must provide a  means  of  tagging
   script invocations, such that the controller can refer to a specified
   script running at a specifed endpoint in subsequent messages.

   R3.3.5 The device control protocol MUST provide  the  means  for  the
   controller to:
    * determine what scripts are active at a given edge-point
    * deactivate a specified script or all scripts  active  at  a  given
      edge-point.


3.4     Tone Signalling

   See the discussion in section 1.4.1.1 for background.  Detection  and
   generation  of tone signalling are events and actions respectively to
   which the scripting requirements of the previous section may apply.

   R3.4.1 The device control  protocol  MUST  allow  the  controller  to
   request  the  generation of tone signalling to specified edge-points.
   Such requests will include designation of the symbols to be sent (see
   requirement  R3.4.3),  the  duration  of  each  symbol,  and the time
   between successive symbols.

   R3.4.2 The device control  protocol  MUST  allow  the  controller  to
   enable  and  disable  the  reporting of tone signalling received from
   specified edge-points.  To avoid unnecessary messaging,  it  must  be
   possible  for  the  controller  to  specify  alternative  patterns of
   signals, the completion of which  should  trigger  a  report  to  the
   controller.   The controller should also be able to specify a timeout
   period beyond which collected events should be reported regardless of
   whether a pattern has been completed.




Taylor                     expires March 1999                  [Page 19]


INTERNET DRAFT        Device Control Requirements         September 1998


   R3.4.3 It is DESIRABLE that the device  control  protocol  provide  a
   language  for  the  reporting of events likely to be encountered with
   the the most common tone signalling systems.  Examples of such events
   are:
    * off- and on-hook, hook-flash, the digits "0" through "D", and  the
      pound "#" and star "*" for tone signalling on lines
    * wink, seizure, release, the digits "0" through "9",  the  elements
      "K0"   through   "K2",  and   the   elements   "S0"  through  "S3"
      for signalling on trunks.

   R3.4.4 As a further elaboration of the  basic  scripting  requirement
   R3.3.2,  the protocol MUST allow invocation of a script combining the
   detection of specified signalling events with  actions  to  be  taken
   upon  detection.   Examples  of  such  use  might  be  to program the
   sequence: "Detect off-hook.  Apply dial  tone.   Listen  for  digits.
   Remove dial tone after a digit is detected.  Collect digits according
   to specified parsing and timeout rules.  Report the results."


3.5     Signalling Backhaul

   R3.5.1 As suggested in section 1.4.1.2, it MAY BE DESIRABLE that  the
   device  control  protocol  provide a means of passing signalling data
   units transparently, along with an identification of  the  signalling
   protocol involved.


3.6     Resource Status Management

   R3.6.1 The device control protocol MUST provide  the  means  for  the
   controller  to  track  failure  conditions affecting call processing.
   Specifically:
    * If a  failure  condition  within  the  Media  Gateway  device  has
      resulted in its failure to execute a  request from the controller,
      means MUST be provided in the Media  Gateway's  response  to   the
      controller to  identify  the   failure   condition   for   further
      reference.

    * It MUST be possible for the controller to determine when
      the failure condition has cleared,  either  by  way  of  a  direct
      notification  within  the  device  control  protocol  itself or by
      other means (e.g. SNMP).

   R3.6.2 The identification of the failure condition SHOULD be such  as
   to  allow  the controller to determine the scope of the failure (e.g.
   specific trunk, entire transmission facility, etc.).

   R3.6.3 The device control protocol MUST provide  the  means  for  the



Taylor                     expires March 1999                  [Page 20]


INTERNET DRAFT        Device Control Requirements         September 1998


   controller to block and unblock the use of specified trunks.


3.7     Other

3.7.1   Vendor Extensibility

   R3.7.1.1 Because device control is a fairly  basic  function,  it  is
   highly  probable  that  vendor-specific  commands,  indications,  and
   attributes or extensions  to  attributes  will  be  required  in  any
   concrete  situation.   The  device  control  protocol MUST be easy to
   extend in these ways.


3.7.2   Architectural Flexibility

   R3.7.2.1  The  device  control  protocol  MUST  be  able  to  operate
   successfully regardless of the location of individual call signalling
   functions and related call processing functions.   It  MUST  also  be
   able  to  operate regardless of the existing arrangements for control
   redundancy.



4.0   Security Aspects

   Security requirements relating to  the  secure  operation  of  an  IP
   device  control session are discussed in section 2.4 above.  Security
   requirements   for   the   handling   of   media   streams    include
   confidentially,   integrity,  and  possibly  authentication.   [ITU-T
   Recommendation H.235 has a good discussion of security  requirements,
   the applicable parts of which could be brought into this document.]



5.0     References

   [1]   F. Cuervo, N. Greene, M. Holdredge, L.  Ong,  and  C.  Huitema,
   "SS7-Internet  Interworking - Architectural Framework", draft-greene-
   ss7-arch-frame-00.txt, July 1998.

   [2]   S. Bradner, "Key words for use in RFCs to Indicate  Requirement
   Levels", RFC 2119, Internet Engineering Task Force, March 1997

   [3]   H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
   A  Transport Protocol for Real-Time Applications," RFC 1889, Internet
   Engineering Task Force, January 1996.




Taylor                     expires March 1999                  [Page 21]


INTERNET DRAFT        Device Control Requirements         September 1998


   [4]   W. Simpson, "The  Point-to-Point  Protocol  (PPP)",  RFC  1548,
   Internet Engineering Task Force, December 1993.



6.0   Acknowledgements

   The following individuals contributed to the  initial  definition  of
   requirements  for  the  IP  device  control protocol, from which this
   document was derived:

   Ilya   Akramovich,  Bob  Bell,  Andrew  Dugan,  Ike   Elliott,   Cary
   Fitzgerald,  Jan  M.  Gronski, Tom Hess, Geoff Jordan, Tony Lam, Pete
   O'Connell, Scott  Pickett,  Shyamal  Prasad,  Eric  Presworsky,  Paul
   Richards,  Dale Skran, Louise Spergel, David Sprague, Raj Srinivasan,
   and Michael Thomas.



7.0   Author's Address

   Questions about this memo can be directed to:

         P. Tom Taylor
         Nortel (Northern Telecom)
         M/S 097, SKY,
         P.O. Box 3511, Station C,
         Ottawa, Ontario,
         Canada

          Phone:  1-613-765-4167
            Fax:  1-613-765-7236
         E-mail:  taylor@nortel.com


















Taylor                     expires March 1999                  [Page 22]