home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipatm-sig-uni-v40-00.txt < prev    next >
Text File  |  1996-03-13  |  23KB  |  623 lines
  1.  
  2. IP over ATM WG                                            M.Maher,A.Mankin
  3. Category: internet-draft                                  February 1996
  4.  
  5.  
  6.  
  7.  
  8.          ATM Signaling Support for IP over ATM - UNI 4.0 Update
  9.                <draft-ietf-ipatm-sig-uni-v40-00.txt>
  10.  
  11. Status of this Memo
  12.  
  13.    This document is an Internet-Draft.  Internet-Drafts are working
  14.    documents of the Internet Engineering Task Force (IETF), its areas,
  15.    and its working groups.  Note that other groups may also distribute
  16.    working documents as Internet-Drafts.
  17.  
  18.    Internet-Drafts are draft documents valid for a maximum of six months
  19.    and may be updated, replaced, or obsoleted by other documents at any
  20.    time.  It is inappropriate to use Internet-Drafts as reference
  21.    material or to cite them other than as ``work in progress.''
  22.  
  23.    To learn the current status of any Internet-Draft, please check the
  24.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  25.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  26.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  27.    Rim).
  28.  
  29.  
  30. Abstract
  31.  
  32.    This memo describes how to efficiently use the ATM call control
  33.    signalling procedures defined in UNI 4.0 [ATMF96] to support IP over
  34.    ATM environments as described in RFC 1577 [LAUB94] and in [KATZ96].
  35.    Among the new features found in UNI 4.0 signalling are negotiation of
  36.    traffic parameters and procedures for Available Bit Rate (ABR)
  37.    signalling.  This initial draft highlights the features of UNI 4.0
  38.    Signalling that provide IP entities capabilities for requesting ATM
  39.    service in sites with SVC support, whether it is private ATM or
  40.    publicly provision ATM, in which case the SVC support is probably
  41.    configured inside PVPs.  This document is not for IP in the presence
  42.    of implemented IP Integrated Services and RSVP.  That will be handled
  43.    by a different specification or set of specifications.
  44.  
  45.    This document is follow-on to RFC 1755, "ATM Signaling Support for IP
  46.    over ATM", which is based on UNI signalling 3.1. Readers are assumed
  47.    to be familiar with RFC 1755.
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Maher,Mankin                                                    [Page 1]
  54.  
  55. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  56.  
  57.  
  58.    1.  Overview
  59.  
  60.    UNI Signalling version 4.0 is the ATM Forum follow-on specification
  61.    to UNI Signalling 3.1. Among the new features in UNI 4.0, those of
  62.    particular interest to IP over ATM enviroments are:
  63.  
  64.        o ABR Signalling for Point-to-Point Calls
  65.        o Traffic Parameter Negotiation
  66.        o Frame Discard Support
  67.        o Leaf Initiated Join (LIJ) Multipoint Capability
  68.        o ATM Anycast Capability
  69.        o Switched Virtual Path (VP) Service
  70.  
  71.    This draft highlights the first three capabilities listed above. The
  72.    last three capabilities are not discussed mainly because models for
  73.    their use in IP over ATM environments have not yet been defined.
  74.  
  75.  
  76.    2.  Overview of Call Establishment Message Content
  77.  
  78.    Signalling messages are structured to contain mandatory and optional
  79.    variable length information elements (IEs).  A SETUP message which
  80.    establishes an ATM connection to be used for IP and multiprotocol
  81.    interconnection calls MUST contain the following IEs:
  82.  
  83.         AAL Parameters
  84.         ATM Traffic Descriptor
  85.         Broadband Bearer Capability
  86.         Broadband Low Layer Information
  87.         QoS Parameter
  88.         Called Party Number
  89.         Calling Party Number
  90.  
  91.    and MAY, under certain circumstance contain the following IEs :
  92.  
  93.         Calling Party Subaddress
  94.         Called Party Subaddress
  95.         Transit Network Selection
  96.  
  97.         (New in UNI 4.0:)
  98.         Minimum Acceptable ATM Traffic Descriptor
  99.         Alternative ATM Traffic Descriptor
  100.         ABR Setup Parameters
  101.         ABR Additional Parameters
  102.         Connection Scope Selection
  103.         Extended QoS Parameters
  104.         End-to-End Transit Delay
  105.  
  106.  
  107.  
  108.  
  109. Maher,Mankin                                                    [Page 2]
  110.  
  111. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  112.  
  113.  
  114.    In UNI 4.0, like UNI 3.1, the AAL Parameters and the Broadband Low
  115.    Layer Information IEs are optional in a SETUP message.  However, in
  116.    support of IP over ATM these two IEs MUST be included. [Appendix A
  117.    will later show a sample setup message for reference]
  118.  
  119.  
  120.    3.  Description of Information Elements
  121.  
  122.    This section describes the coding of, and procedures surrounding,
  123.    information elements in a SETUP message. The first two IEs described,
  124.    ATM Adaptation Layer Parameters and Broadband Low Layer Information,
  125.    are categorized as having significance only to the endpoints of an
  126.    ATM call supporting IP. That is, the network does not process these
  127.    IEs.
  128.  
  129.  
  130.    3.1.  ATM Adaptation Layer (AAL) Parameters
  131.  
  132.    The AAL Parameters IE carries information about the ATM adaptation
  133.    layer to be used on the connection. The parameters specified in this
  134.    IE are the same as specified in [PER94].
  135.  
  136.           Format and field values of AAL Parameters IE
  137.  
  138.           ----------------------------------------------------------
  139.           | aal_parameters                                         |
  140.           ----------------------------------------------------------
  141.           |  aal_type                    5        (AAL 5)          |
  142.           |  fwd_max_sdu_size_identifier 140                       |
  143.           |  fwd_max_sdu_size            65,535   (desired IP MTU) |
  144.           |  bkw_max_sdu_size_identifier 129                       |
  145.           |  bkw_max_sdu_size            65,535   (desired IP MTU) |
  146.           |  sscs_type identifier        132                       |
  147.           |  sscs_type                   0        (null SSCS)      |
  148.           ----------------------------------------------------------
  149.  
  150.    This shows maximum size MTUs.  In practice, most sites have used 9180
  151.    IP MTUs for ATM [RFC1626].
  152.  
  153.    3.2.  Broadband Low Layer Information
  154.  
  155.    Selection of an encapsulation to support IP over an ATM VCC is done
  156.    using the Broadband Low Layer Information (B-LLI) IE, along with the
  157.    AAL Parameters IE, and the B-LLI negotiation procedure.  B-LLI nego-
  158.    tiation is described in [PER94] in Appendix D. The procedures remain
  159.    the same for this UNI 4.0 based specification.
  160.  
  161.           Format of B-LLI IE indicating LLC/SNAP encapsulation
  162.  
  163.  
  164.  
  165. Maher,Mankin                                                    [Page 3]
  166.  
  167. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  168.  
  169.  
  170.           ----------------------------------------------------------
  171.           | bb_low_layer_information                               |
  172.           ----------------------------------------------------------
  173.           |  layer_2_id                 2                          |
  174.           |  user_information_layer     12  (lan_llc - ISO 8802/2) |
  175.           ----------------------------------------------------------
  176.  
  177.  
  178.  
  179.    3.3.  Traffic Management Issues
  180.  
  181.    The ATM Forum Traffic Management Sub-working group is nearing comple-
  182.    tion of version 4.0 of their specification [TMGT96]. This latest ver-
  183.    sion focuses primarily on the definition of the ABR traffic category.
  184.    As opposed to the Unspecified Bit Rate (UBR) traffic class, ABR uses
  185.    a rate-based flow control mechanism to assure certain traffic guaran-
  186.    tees (bandwidth and delay).  There has been much debate on whether IP
  187.    benefits from ABR, and if so, how IP should use ABR. The Integrated
  188.    Internet Services (IIS) and RSVP models in IP add complexity to this
  189.    issue because mapping IIS traffic classes to ATM traffic classes is
  190.    not straightforward.
  191.  
  192.    This draft attempts only to present the required IP to ATM signalling
  193.    interface for IP over ATM systems that do not support IIS as yet.  It
  194.    is an attempt to cause IP over ATM vendors to support enough options
  195.    for signalling the traffic characteristics of VCs serving non-IIS IP
  196.    datagrams so that sites can configure their IP over ATM to conform to
  197.    the varied services that their ATM provider may have sold to them.
  198.    By definition, IP without IIS cannot be expected to provide a signal-
  199.    ling interface that is flexible and allows application specific
  200.    traffic descriptors.
  201.  
  202.    The potential services that an IP over ATM interface may be config-
  203.    ured for are:
  204.  
  205.     - CBR
  206.     - CBR with CLR specified (loss-permitting CBR)
  207.     - ABR
  208.     - UBR
  209.     - non-real time VBR
  210.  
  211.    [We don't think it's likely that realtime VBR would be a provisioned
  212.    service to a site, but we expect to discuss this with the WG]
  213.  
  214.    The topic of IP over ATM signalling for IP _with_ IIS/RSVP is to be
  215.    presented in another specification [and a BOF is occurring to work on
  216.    the elements of it at the LA IETF].
  217.  
  218.  
  219.  
  220.  
  221. Maher,Mankin                                                    [Page 4]
  222.  
  223. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  224.  
  225.  
  226.    The Traffic Descriptor IE, Broadband Bearer Capability IE, and the
  227.    QoS Parameter IE together define the signalling view of ATM traffic
  228.    management.  In this memo, we present an agreed-on, required subset
  229.    of traffic management capabilities, as specified by using these three
  230.    IEs.  The table below shows a set of the allowable combinations of
  231.    traffic parameters.  This subset includes all forms of non-IIS IP
  232.    signalling configurations that must be implemented to accomodate
  233.    varied sites' needs.
  234.  
  235.    The list of the subsetted forms is above.  The principle is that IP
  236.    over ATM service may be provided by different sites by different
  237.    types of procured ATM service; for one site, a CBR PVP might be
  238.    cost-effective and then the SVCs that IP over ATM without IIS must
  239.    establish must be CBR.  Similarly, VBR, or ABR.  We want to fill in
  240.    the table parameters to offer the most sensible parameters within
  241.    this non-IIS configuration.  For instance, for non-IIS VBR, the SCR
  242.    value may need to be hand-configured on IP users.  Or for ABR, the
  243.    PCR value may be link-rate with a 0 MCR.  Completing this table will
  244.    be iterated in WG discussion.
  245.  
  246.  
  247.  
  248.    All IP over ATM endsystems MUST support this minimal set of combina-
  249.    tions in their ATM signalling.
  250.  
  251.    [Below you will find a handy summary of the ATM Forum 4.0 signalling
  252.    subset for all TM and then a table of traffic descriptor parameters
  253.    for the subsets for IP without IIS, however these will both be filled
  254.    in in the next draft of this memo]
  255.  
  256.    [Handy Summary]
  257.                  Combinations of Traffic Related Parameters
  258.                  that MAY be supported in the SETUP message
  259.  
  260.    [To be added later]
  261.  
  262.     (This table will be a reproduction of Table 9-1 of Annex 9 in
  263.    [ATMF96])
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277. Maher,Mankin                                                    [Page 5]
  278.  
  279. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  280.  
  281.  
  282.    3.3.1.  ATM Traffic Descriptor
  283.  
  284.    Disregarding IIS and RSVP, the most convenient model of IP behavior
  285.    corresponds to the Best Effort Capability.  Best effort service MAY
  286.    be requested by including the forward and backward peak cell rate
  287.    (CLP=0+1) and the Best Effort Indicator fields in the ATM Traffic
  288.    Descriptor IE. As stated above, this may not be the choice that a
  289.    site's configuration allows.
  290.  
  291.    In support of ABR service two new subfields have been added to the
  292.    Traffic Descriptor IE, forward and backward 'Minimum Cell Rate'
  293.    fields.
  294.  
  295.  
  296.    3.3.2.  Traffic Parameter Negotiation
  297.  
  298.    UNI 4.0 allows certain traffic parameters to be negotiated during the
  299.    call establishment phase (see section 8 of UNI 4.0). Traffic parame-
  300.    ters cannot be 'renegotiated' after the call is active. Two specific
  301.    capabilities are defined:
  302.  
  303.      - negotiation of PCR parameters (using the Minimum Acceptable ATM
  304.        Traffic Descriptor IE)
  305.      - negotiation of other traffic parameters (using the Alternative
  306.        ATM Traffic Descriptor IE)
  307.  
  308.    A SETUP or CONNECT message may include ONLY one of the above IEs.
  309.    That is, the calling party may only offer an 'alternative' or
  310.    'minimum' to the requested traffic parameters. In order to take
  311.    advantage of these negotiation procedures, IP over ATM entities
  312.    SHOULD specify PCR _equal_ to the link rate in the ATM Traffic
  313.    Descriptor IE and a known minimum in the Minimum Acceptable ATM
  314.    Traffic Descriptor IE.
  315.  
  316.  
  317.    3.3.3.  Frame Discard Capability
  318.  
  319.    The frame discard capabilty in UNI 4.0 is primarily based on the any
  320.    of the ATM services, except for loss-less CBR.  Frame discard signal-
  321.    ling MUST be supported by all IP over ATM entities and it is RECOM-
  322.    MENDED that frame discard be signalled for all IP SVCs because it has
  323.    been proven to increase throughput under network congestion. Signal-
  324.    ling for frame discard is done by setting the frame discard bit in
  325.    the 'Traffic Management Options' subfield in the Traffic Descriptor
  326.    IE.  It is possible that not all network entities in the SVC path
  327.    support frame discard, but it is requiered that they all forward the
  328.    signalling.
  329.  
  330.  
  331.  
  332.  
  333. Maher,Mankin                                                    [Page 6]
  334.  
  335. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  336.  
  337.  
  338.    3.4.  ABR Signalling In More Detail
  339.  
  340.    [This is VERY DRAFTY] Two new IEs have been defined for ABR signal-
  341.    ling:
  342.  
  343.       o ABR Setup Parameters
  344.       o ABR Additional Parameters
  345.  
  346.    These IEs may be optionally included in a SETUP or CONNECT message.
  347.    The ABR Setup Parameters IE contains the following subfields:
  348.  
  349.       - Forward/Backward ABR Initital Cell Rate
  350.       - Forward/Backward ABR Transient Buffer Exposure
  351.       - Cumulative RM Fixed Round Trip Time
  352.       - Forward/Backward Rate Increment Factor
  353.       - Forward/Backward Rate Decrease Factor
  354.  
  355.    The ABR Additional Parameters IE contains one subfield:
  356.  
  357.       - Forward/Backward Additional Parameters Record
  358.  
  359.    The Additional Parameters Record value is a compressed encoding of a
  360.    set of ABR parameters (see TMGT96).
  361.  
  362.  
  363.    3.5.  Broadband Bearer Capability
  364.  
  365.    Broadband Bearer Connection Oriented Service Type X (BCOB-X) or Type
  366.    C (BCOB-C) are both applicable for multiprotocol interconnection,
  367.    depending on the service(s) provided by the ATM network and the capa-
  368.    bilities (e.g. for traffic shaping) of the ATM endsystem. The table
  369.    in the previous section showed the use of BCOB-X and BCOB-C with
  370.    other parameters.  The figure below shows format and field values for
  371.    a BCOB-X when the Traffic Descriptor IE indicates Best Effort.
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390. Maher,Mankin                                                    [Page 7]
  391.  
  392. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  393.  
  394.  
  395.           Format and field values of Broadband Bearer Capability IE
  396.  
  397.           ----------------------------------------------------------
  398.           | bb_bearer_capability                                   |
  399.           ----------------------------------------------------------
  400.           |  spare                       0                         |
  401.           |  bearer_class                16      (BCOC-X)          |
  402.           |  traffic_type                cbr, rt-vbr, nrt-vbr, abr |
  403.           |  spare                       0                         |
  404.           |  user_plane_configuration    0       (point_to_point)  |
  405.           ----------------------------------------------------------
  406.  
  407.  
  408.    IP over ATM signaling MUST permit BCOB-C and BCOB-X, in the combina-
  409.    tions shown in the previous section.  It MAY also permit one of the
  410.    allowable combinations shown in Appendix XX.
  411.  
  412.  
  413.    3.6.  QoS Parameter
  414.  
  415.    The Unspecified QoS class (Class 0) is the only QoS class that must
  416.    be supported by all networks and the only QoS class allowed when
  417.    using the Best Effort service. The Specified QoS Class for Connection
  418.    Oriented Data Transfer (Class 3) or the Specified QoS Class for Con-
  419.    nectionless Data Transfer (Class 4)  may be applicable to multiproto-
  420.    col over ATM, but their use has to be negotiated with the network
  421.    provider.  The combinations of QoS parameters with the ATM Traffic
  422.    Descriptor and the Broadband Bearer Capability are detailed in the
  423.    Traffic Descriptor section [and will be fleshed out later -- this
  424.    section is drafty as yet]
  425.  
  426.           Format and field values of QoS Parameters IE
  427.  
  428.           ----------------------------------------------------------
  429.           | qos_parameter                                          |
  430.           ----------------------------------------------------------
  431.           |  qos_class_fwd              0         (class 0)        |
  432.           |  qos_class_bkw              0         (class 0)        |
  433.           ----------------------------------------------------------
  434.  
  435.  
  436.    3.7.  Signalling of Individual QoS Parameters
  437.  
  438.    [Drafty] UNI 4.0 allows for signalling of individual QoS parameters
  439.    for the purpose of explicitly informing the network and called party
  440.    of certain desired delay and cell loss characterics. The two indivi-
  441.    dual QoS parameter IEs, Extended QoS Parameters IE and End-to-End
  442.    Transit Delay, can be used in the SETUP and CONNECT signalling
  443.  
  444.  
  445.  
  446. Maher,Mankin                                                    [Page 8]
  447.  
  448. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  449.  
  450.  
  451.    messages in place of the 'generic' QoS Parameter IE. Nevertheless,
  452.    inclusion of these two IEs depends on the type of ATM service
  453.    category requested.  (see Annex 9 in [ATMF96])
  454.  
  455.  
  456.    3.8.  ATM Addressing Information
  457.  
  458.    ATM addressing information is carried in the Called Party Number,
  459.    Calling Party Number, and, under certain circumstance, Called Party
  460.    Subaddress, and Calling Party Subaddress IE. Section 5.8 of [ATMF93]
  461.    provides the procedure for an ATM endsystem to learn its own ATM
  462.    address from the ATM network, for use in populating the Calling Party
  463.    Number IE.  Section 5.4.5.14 [ATMF94] describes the syntax and seman-
  464.    tics of the calling party subaddress IE.
  465.  
  466.  
  467.           Format and field values of Called and Calling Party Number IE
  468.  
  469.           ----------------------------------------------------------
  470.           | called_party_number                                    |
  471.           ----------------------------------------------------------
  472.           |  type_of_number      (international number / unknown)  |
  473.           |  addr_plan_ident     (ISDN / ATM Endsystem Address)    |
  474.           |  addr_number         (E.164 / ATM Endsystem Address)   |
  475.           ----------------------------------------------------------
  476.  
  477.  
  478.           ----------------------------------------------------------
  479.           | calling_party_number                                   |
  480.           ----------------------------------------------------------
  481.           |  type_of_number      (international number / unknown)  |
  482.           |  addr_plan_ident     (ISDN / ATM Endsystem Address)    |
  483.           |  presentation_indic  (presentation allowed)            |
  484.           |  spare               0                                 |
  485.           |  screening_indic     (user provided verified & passed) |
  486.           |  addr_number         (E.164 / ATM Endsystem Address    |
  487.           ----------------------------------------------------------
  488.  
  489.  
  490.  
  491.  
  492.    4.  Security Considerations
  493.  
  494.    The ATM Forum recently established an ATM Security sub-working group
  495.    in for the purpose of defining seurity mechanisms in ATM. It is
  496.    therefore premature to begin defining IP over ATM signalling's use of
  497.    ATM security.  IP Security (RFC1825) can be applied to IP datagrams
  498.    over any medium.
  499.  
  500.  
  501.  
  502. Maher,Mankin                                                    [Page 9]
  503.  
  504. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  505.  
  506.  
  507.    5.  Open Issues
  508.  
  509.    Description of Leaf Initiated Join (LIJ) signalling is not discussed
  510.    because the use of LIJ in IP over ATM has not been defined.  
  511.  
  512.    [Plus issues associated with those various drafty bits]
  513.  
  514. REFERENCES
  515.  
  516.    [LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC1577,
  517.        Hewlett-Packard Laboratories, December 1993
  518.  
  519.    [ATMF94] ATM Forum, "ATM User-Network Interface Specification Version
  520.        3.1", (Englewood Cliffs, NJ: Prentice Hall, 1994)
  521.  
  522.    [ATMF96] ATM Forum, "ATM User-Network Interface Specification Version
  523.        4.0", 1996 Work in Progress.
  524.  
  525.    [TMGT96] ATM Forum, "ATM Forum Traffic Management Specification Ver-
  526.        sion 4.0", 1996, Work in Progress.
  527.  
  528.    [KAT96] "NBMA Next Hop Resolution Protocol (NHRP)", Katz, Piscitello,
  529.        Cole, Luciani, draft-ietf-rolc-nhrp-07.txt.
  530.  
  531.    [BRAD89] Braden, R., Editor, "Requirements for Internet Hosts -- Com-
  532.        munication Layers", RFC 1122, USC/Information Science Institute,
  533.        October 1989.
  534.  
  535.    [BRAD94] Braden, R., Clark, D, Shenker, S., "Integrated Service in
  536.        the Internet Architecture:  An Overview", RFC 1633,
  537.        USC/Information Science Institute, June 1994.
  538.  
  539.    [BRAD96] Braden, R., et al, "RSVP Protocol Function Specification",
  540.        Work in Progress.
  541.  
  542.    [HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM Adapta-
  543.        tion Layer 5", RFC 1483, Telecom Finland, July 1993.
  544.  
  545.    [ISO8473] ISO/IEC 8473, Information processing systems - Data commun-
  546.        ications - Protocol for providing the connectionless-mode network
  547.        service, 1988.
  548.  
  549.    [ISO9577] Information Technology - Telecommunication and information
  550.        exchange between systems - Protocol identification in the network
  551.        layer ISO/IEC TR9577 (International Standards Organization:
  552.        Geneva, 1990)
  553.  
  554.    [ROM94] Romanow, A., and Floyd, S., Dynamics of TCP Traffic over ATM
  555.        Networks.  IEEE JSAC, V. 13 N. 4, May 1995, p. 633-641. Abstract.
  556.        An earlier version appeared in SIGCOMM '94, August 1994, pp. 79-
  557.        88.
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564. Maher,Mankin                                                   [Page 10]
  565.  
  566. RFC             IP over ATM Signalling - UNI 4.0 Update    February 1996
  567.  
  568.  
  569.    [PART92] Partridge, C., "A Proposed Flow Specification", RFC1363,
  570.        BBN, September 92
  571.  
  572.    [Q.2931] Broadband Integrated Service Digital Network (B-ISDN) Digi-
  573.        tal Subscriber Signaling System No.2 (DSS2) User Network Inter-
  574.        face Layer 3 Specification for Basic Call/Connection Control
  575.        ITU-T Recommendation Q.2931, (International Telecommunication
  576.        Union: Geneva, 1994)
  577.  
  578. Authors' Information
  579.  
  580.    Maryann Perez Maher
  581.    maher@isi.edu
  582.  
  583.    Allison Mankin
  584.    mankin@isi.edu
  585.  
  586.    USC/Information Sciences Institute
  587.    4350 N. Fairfax Drive, Suite 620
  588.    Arlington VA 22203
  589.    703-807-0133
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621. Maher,Mankin                                                   [Page 11]
  622.  
  623.