rfc3108.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,523 行 · 第 1/5 页

Network Working Group                                           R. Kumar
Request for Comments: 3108                                    M. Mostafa
Category: Standards Track                                  Cisco Systems
                                                                May 2001


   Conventions for the use of the Session Description Protocol (SDP)
                       for ATM Bearer Connections

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes conventions for using the Session Description
   Protocol (SDP) described in RFC 2327 for controlling ATM Bearer
   Connections, and any associated ATM Adaptation Layer (AAL).  The AALs
   addressed are Type 1, Type 2 and Type 5.  This list of conventions is
   meant to be exhaustive.  Individual applications can use subsets of
   these conventions.  Further, these conventions are meant to comply
   strictly with the SDP syntax as defined in RFC 2327.

Table of Contents

   1. Introduction...................................................  3
   1.1  Key words to indicate Requirement Levels.....................  5
   2. Representation of Certain Fields within SDP description lines..  5
   2.1  Representation of Extension Attributes.......................  5
   2.2  Representation of Parameter Values...........................  5
   2.3  Directionality Convention....................................  6
   2.4 Case convention...............................................  7
   2.5 Use of special characters in SDP parameter values.............  8
   3. Capabilities Provided by SDP conventions.......................  8
   4. Format of the ATM Session Description..........................  9
   5.  Structure of the Session Description Lines.................... 11
   5.1  The Origin Line.............................................. 11
   5.2  The Session Name Line........................................ 12
   5.3  The Connection Information Line.............................. 13
   5.4  The Timestamp Line........................................... 15



Kumar & Mostafa             Standards Track                     [Page 1]

RFC 3108                        ATM SDP                         May 2001


   5.5  Media Information Line for ATM connections................... 16
   5.5.1  The Virtual Connection ID.................................. 16
   5.5.2  The Transport Parameter.................................... 19
   5.5.3  The Format List for AAL1 and AAL5 applications............. 21
   5.5.4  The Format List for AAL2 applications...................... 21
   5.5.5  Media information line construction........................ 22
   5.6  The Media Attribute Lines.................................... 27
   5.6.1  ATM bearer connection attributes........................... 28
   5.6.1.1  The 'eecid' attribute.................................... 30
   5.6.1.2  The 'aalType' attribute.................................. 31
   5.6.1.3  The 'capability' attribute............................... 32
   5.6.1.4  The 'qosClass' attribute................................. 33
   5.6.1.5  The 'bcob' attribute..................................... 34
   5.6.1.6  The 'stc' attribute...................................... 34
   5.6.1.7  The 'upcc' attribute..................................... 35
   5.6.1.8  The 'atmQOSparms' attribute.............................. 35
   5.6.1.9  The 'atmTrfcDesc'  attribute............................. 37
   5.6.1.10 The 'abrParms' attribute................................. 39
   5.6.1.11 The 'abrSetup' attribute................................. 40
   5.6.1.12 The 'bearerType' attribute............................... 41
   5.6.1.13 The 'lij' attribute...................................... 42
   5.6.1.14 The 'anycast' attribute.................................. 43
   5.6.1.15 The 'cache' attribute.................................... 43
   5.6.1.16 The 'bearerSigIE' attribute.............................. 44
   5.6.2  ATM Adaptation Layer (AAL) attributes...................... 45
   5.6.2.1  The 'aalApp' attribute................................... 46
   5.6.2.2  The 'cbrRate' attribute.................................. 48
   5.6.2.3  The 'sbc' attribute...................................... 49
   5.6.2.4  The 'clkrec' attribute................................... 51
   5.6.2.5  The 'fec' attribute...................................... 51
   5.6.2.6  The 'prtfl' attribute.................................... 51
   5.6.2.7  The 'structure' attribute................................ 52
   5.6.2.8  The 'cpsSDUsize' attribute............................... 53
   5.6.2.9  The 'aal2CPS' attribute.................................. 53
   5.6.2.10 The 'aal2CPSSDUrate' attribute........................... 54
   5.6.2.11 The 'aal2sscs3661unassured' attribute.................... 54
   5.6.2.12 The 'aal2sscs3661assured' attribute...................... 55
   5.6.2.13 The 'aal2sscs3662' attribute............................. 56
   5.6.2.14 The 'aal5sscop' attribute................................ 58
   5.6.3  Service attributes......................................... 58
   5.6.3.1  The 'atmmap' attribute................................... 60
   5.6.3.2  The 'silenceSupp' attribute.............................. 63
   5.6.3.3  The 'ecan' attribute..................................... 65
   5.6.3.4  The 'gc' attributes...................................... 66
   5.6.3.5  The 'profileDesc' attribute.............................. 67
   5.6.3.6  The 'vsel' attribute..................................... 68
   5.6.3.7  The 'dsel' attribute..................................... 70
   5.6.3.8  The 'fsel' attribute..................................... 72



Kumar & Mostafa             Standards Track                     [Page 2]

RFC 3108                        ATM SDP                         May 2001


   5.6.3.9  The 'onewaySel' attribute................................ 73
   5.6.3.10 The 'codecconfig' attribute.............................. 75
   5.6.3.11 The 'isup_usi' attribute................................. 76
   5.6.3.12 The 'uiLayer1_Prot' attribute............................ 76
   5.6.4  Miscellaneous media attributes............................. 77
   5.6.4.1 The 'chain' attribute..................................... 77
   5.6.5  Use of the second media-level part in H.323 Annex C
          applications............................................... 78
   5.6.6  Use of the eecid media attribute in call establishment
          procedures................................................. 78
   6. List of Parameters with  Representations....................... 83
   7. Examples of ATM session descriptions using SDP................. 93
   8. Security Considerations........................................ 94
   8.1  Bearer Security.............................................. 94
   8.2  Security of the SDP description.............................. 95
   9. ATM SDP Grammar................................................ 95
   References........................................................104
   Acknowledgements..................................................109
   Authors' Addresses................................................109
   Full Copyright Statement..........................................110

1. Introduction

   SDP will be used in conjunction with a connection handling /device
   control protocol such as Megaco (H.248) [26], SIP [18] or MGCP [25]
   to communicate the information needed to set up ATM and AAL2 bearer
   connections.  These connections include voice connections, voiceband
   data connections, clear channel circuit emulation connections, video
   connections and baseband data connections (such as fax relay, modem
   relay, SSCOP, frame relay etc.).

   These conventions use standard SDP syntax as defined in RFC 2327 [1]
   to describe the ATM-level and AAL-level connections, addresses and
   other parameters.  In general, parameters associated with layers
   higher than the ATM adaptation layer are included only if they are
   tightly coupled to the ATM or AAL layers.  Since the syntax conforms
   to RFC 2327, standard SDP parsers should react in a well-defined and
   safe manner on receiving session descriptions based on the SDP
   conventions in this document.  This is done by extending the values
   of fields defined in RFC 2327 rather than by defining new fields.
   This is true for all SDP lines except the of the media attribute
   lines, in which case new attributes are defined.  The SDP protocol
   allows the definition of new attributes in the media attribute lines
   which are free-form.  For the remaining lines, the fact that the
   <networkType> field in an SDP descriptor is set to "ATM" should
   preclude the misinterpretation of extended parameter values by RFC
   2327-compliant SDP parsers.




Kumar & Mostafa             Standards Track                     [Page 3]

RFC 3108                        ATM SDP                         May 2001


   These conventions are meant to address the following ATM
   applications:

      1. Applications in which a new SVC is set-up for each service
         connection.  These SVCs could be AAL1 or AAL5 SVCs or single-
         CID AAL2 SVCs.

      2. Applications in which existing path resources are assigned to
         service connections.  These resources could be:

         *  AAL1/AAL5 PVCs, SPVCs or cached SVCs,
         *  AAL2 single-CID PVCs, SPVCs or cached SVCs,
         *  CIDs within AAL2 SVCs/PVCs/SPVCs that multiplex multiple
            CIDs.
         *  Subchannels (identified by CIDs) within AAL1 [8] or AAL2
            [11] SVCs/PVCs/SPVCs.

   Note that the difference between PVCs and SPVCs is in the way the
   bearer virtual circuit connection is set up.  SPVCs are a class of
   PVCs that use bearer signaling, as opposed to node-by-node
   provisioning, for connection establishment.

   This document is limited to the case when the network type is ATM.
   This includes raw RTP encapsulation [45] or voice sample
   encapsulation [46] over AAL5 with no intervening IP layer.  It does
   not address SDP usage for IP, with or without ATM as a lower layer.

   In some cases, IP connection set-up is independent of lower layers,
   which are configured prior to it.  For example, AAL5 PVCs that
   connect IP routers can be used for VoIP calls.  In other cases, VoIP
   call set-up is closely tied to ATM-level connection set-up.  This
   might require a chaining of IP and ATM descriptors, as described in
   section 5.6.4.1.

   This document makes no assumptions on who constructs the session
   descriptions (media gateway, intermediate ATM/AAL2 switch, media
   gateway controller etc.).  This will be different in different
   applications.  Further, it allows the use of one session description
   for both directions of a connection (as in SIP and MGCP applications)
   or the use of separate session descriptions for different directions.
   It also addresses the ATM multicast and anycast capabilities.

   This document makes no assumptions about how the SDP description will
   be coded.  Although the descriptions shown here are encoded as text,
   alternate codings are possible:

   -  Binary encoding such as ASN.1.  This is an option (in addition to
      text encoding) in the Megaco context.



Kumar & Mostafa             Standards Track                     [Page 4]

RFC 3108                        ATM SDP                         May 2001


   -  Use of extended ISUP parameters [36] to encode the information in
      SDP descriptors, with conversion to/from binary/text-based SDP
      encoding when needed.

1.1 Key words to indicate Requirement Levels

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [62].

2. Representation of Certain Fields within SDP description lines

   This document conforms to the syntactic conventions of standard SDP
   as defined in RFC 2327 [1].

2.1  Representation of Extension Attributes

   The SDP protocol [1] requires that non-standard attributes and codec
   names use an "X-" prefix.

   In this internet document, the "X-" prefix is used consistently for
   codec names (Table 2) that have not been registered with the IANA.
   The IANA-registered codec names listed in [31] do not use this
   prefix, regardless of  whether they are statically or dynamically
   assigned payload types.

   However, this prefix is not used for the extension SDP attributes
   defined in this document.  This has been done to enhance legibility.

   This document suggests that parsers be flexible in the use of the
   "X-" prefix convention.  They should accept codec names and attribute
   names with or without the "X-" prefix.

2.2 Representation of Parameter Values

   Depending on the format of their representation in SDP, the
   parameters defined in this document fall into the following classes:

   (1) Parameters always represented in a decimal format.
   (2) Parameters always represented in a hexadecimal format.
   (3) Parameters always represented as character strings.
   (4) Parameters that can be represented in either decimal or
       hexadecimal format.

   No prefixes are needed for classes 1 - 3, since the format is fixed.
   For class 4, a "0x" prefix shall always be used to differentiate the
   hexadecimal from the decimal format.




Kumar & Mostafa             Standards Track                     [Page 5]

RFC 3108                        ATM SDP                         May 2001


   For both decimal and hex representations, if the underlying bit field
   is smaller or larger than the binary equivalent of the SDP
   representation, then leading 0 bits should be added or removed as
   needed.  Thus, 3 and 0x3 translate into the following five-bit
   pattern: 0 0011.  The SDP representations 0x12 and 18 translate into
   the following five-bit pattern: 1 0010.

   Leading 0 digits shall not be used in decimal representations.
   Generally, these are also not used in hexadecimal representations.
   Exceptions are when an exact number of hex digits is expected, as in
   the case of NSAP addresses.  Parsers shall not reject leading zeros
   in hex values.

   Both single-character and multi-character string values are enclosed
   in double quotes (i.e., ").  By contrast, single quotes (i.e., ') are
   used for emphasizing keywords rather than to refer to characters or
   strings.

   In the text representation of decimal and hex numbers, digits to the