rfc-3108

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

R. Kumar, M. Mostafa
date2001-05 streamIETF areaart wgmmusic statusPROPOSED STANDARD pages110 canonicalhttps://www.rfc-editor.org/rfc/rfc3108 doi10.17487/RFC3108 errataview
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. [STANDARDS-TRACK]

Extracted elements (25)

design-rationale §1

The document extends existing SDP field values rather than defining new SDP fields, so that standard RFC 2327-compliant parsers react in a well-defined and safe manner when the <networkType> is 'ATM'. New attributes are introduced only in the media attribute ('a') lines, where RFC 2327 explicitly permits free-form extensions.

security

design-rationale §5.6.1.1

The neutral term 'eecid' is used in SDP session descriptors instead of 'bnc-id' in order to provide a common SDP baseline for both ISUP/Q.1901 applications and SIP/SIP+ applications, since 'backbone network connection identifier' implies a scope that does not match SIP usage.

design-rationale §2.3

The SDP forward/backward convention (away from the local node = forward) differs from the ATM signaling convention (Q.2931/Q.2630.1 forward = from setup-initiating end). In the backward SVC call setup model a media gateway must swap direction labels when mapping between SDP descriptors and ATM bearer signaling messages.

design-rationale §2.1

The 'X-' prefix is omitted from the extension SDP attributes defined in this document (though it is retained for non-IANA-registered codec names) in order to enhance legibility. Parsers are suggested to accept attribute names with or without the 'X-' prefix.

interoperability-note §2.4

SDP syntax is case-sensitive per RFC 2327, and these ATM conventions strictly conform to that rule. However, it is suggested (but not required) that SDP parsers for ATM applications be case-tolerant where ignoring case does not introduce ambiguity. Encoding names defined outside the SDP protocol are case-insensitive.

interoperability-note §5.5.5

The transport value 'AAL1/AVP' used in previous versions of this document is considered equivalent to 'AAL1/ATMF'. The value 'AAL1/AVP' is unsuitable going forward because the AVP profile is closely tied to RTP, whereas AAL1/ATMF references the correct ATMF standard.

normative-requirement §2.2 SHALL

For class 4 parameters (those representable in either decimal or hexadecimal), a '0x' prefix SHALL always be used to distinguish the hexadecimal format from the decimal format. Leading zeros SHALL NOT be used in decimal representations; parsers shall not reject leading zeros in hex values.

normative-requirement §5.6.1.1 RECOMMENDED

It is RECOMMENDED that the eecid be retained until the connection terminates rather than released as soon as the bearer setup message is received. Because the eecid space (32 bits) is large enough, early release is not necessary.

normative-requirement §5.6 MUST NOT

Media attribute lines MUST NOT contradict each other or other SDP lines; inconsistencies are not to be ignored and SHOULD be flagged as errors. Repeated media attribute lines may carry additional information but SHOULD NOT be inconsistent with each other.

normative-requirement §2.3 MUST

The forward/backward directionality convention—where 'forward' means away from the ATM node under consideration and 'backward' means toward it—MUST be used in all SDP-based session descriptions, regardless of whether the bearer is an SVC, PVC/SPVC, or dynamically allocated CID, and independently of which side originates the connection.

normative-requirement §4 SHOULD

The <networkType> field in ATM SDP descriptions SHOULD be set to the string value 'ATM' or wildcarded to '$' or '-'. The 'v' line is strongly RECOMMENDED at the beginning of each SDP session description; in Megaco contexts it is optional but MUST be present when multiple session descriptions are provided in sequence, where it serves as a delimiter.

protocol-element §5.6.1.2

The 'aalType' attribute indicates the ATM Adaptation Layer in use. Valid string values are: 'AAL1', 'AAL1_SDT', 'AAL1_UDT', 'AAL2', 'AAL3/4', 'AAL5', and 'USER_DEFINED_AAL'. This attribute may be omitted when its value is redundant with the 'm' line transport field.

protocol-element §5.6.1.8

The 'atmQOSparms' attribute describes ATM QoS parameters including acceptable and cumulative CDV (24-bit, microseconds), end-to-end and cumulative transit delay (16-bit, milliseconds), and acceptable cell loss ratio (8-bit order-of-magnitude exponent). A <directionFlag> of 'f', 'b', or 'fb' applies parameters to forward, backward, or both directions.

protocol-element §5.6.1.9

The 'atmTrfcDesc' attribute describes ATM traffic descriptor parameters: PCR, SCR, MBS, CDVT, MCR, MFS (all decimal integers), and frame-discard-allowed (<fd>) and CLP-tagging-enabled (<te>) flags. A <clpLvl> subfield ('0', '0+1', or '-') scopes the descriptor to cells of that CLP value; separate attribute lines are needed if both CLP levels are described.

protocol-element §5.6.1.3

The 'capability' attribute indicates the ATM Service Category (ATMF) or ATM Transfer Capability (ITU I.371). Supported <asc> values are CBR, nrt-VBR, rt-VBR, UBR, ABR, and GFR; supported <atc> values are DBR, SBR, ABT/IT, ABT/DT, and ABR. An integer <subtype> field further qualifies the service category per ITU Q.2931 and ATMF TM 4.1.

protocol-element §5.3

The connection information line for ATM networks supports three <addressType> values: NSAP (40 hex-digit dotted notation), E164 (decimal number up to 15 digits), and GWID or ALIAS (alphanumeric string up to 32 characters identifying a gateway or node alias). Each of the three fields may be independently wildcarded to '$' or '-'.

protocol-element §5.6.1.1

The 'eecid' (end-to-end connection identifier) attribute is synonymous with the 4-byte 'bnc-id' parameter used by ITU Q.1901. It correlates service-level connections with ATM bearer connections: in the forward SVC model the call-terminating gateway selects and transmits the eecid; in the backward model the call-originating gateway does. Its value need only be unique within the SVC-terminating node.

protocol-element §5.5.2

The <transport> parameter in the 'm' line specifies the encapsulation standard for the service payload. Defined values include AAL1/ATMF, AAL1/ITU, AAL5/ATMF, AAL5/ITU, AAL2/ATMF, AAL2/ITU, AAL1/custom, AAL2/custom, AAL5/custom, corporate-name variants, IEEE OUI variants, and RTP/AVP (for H.323 Annex C applications).

protocol-element §5.5.1

The <virtualConnectionId> replaces the <port> field of RFC 2327's 'm' line and identifies the ATM virtual circuit or subchannel. Formats include VCCI, VPI/VCI, VPCI/VCI, BCG/VPI/VCI, and port-qualified forms; any term may be qualified with an optional ATM remote-peer address. For AAL2, a CID suffix is appended to identify the subchannel.

protocol-element §2.5

The '$' wildcard allows the SDP recipient to select any permitted value for a parameter. The '-' value indicates the parameter is irrelevant or obtainable from another source (provisioning, defaults, another protocol). The strings 'CHOOSE' and 'OMIT' may be used in lieu of '$' and '-' respectively if special characters are construed as RFC 2327 violations.

security-consideration §8.1

ATM and AAL2 bearer encryption has not been conventionalized at the time of publication; neither has the authentication or encryption of ATM or AAL2 bearer signaling. The SDP encryption key line (k=) can indicate an encryption key and retrieval method, but its use for ATM bearers is not standardized.

security

security-consideration §8.2

The SDP session description itself must be protected against unauthorized modification and interception, since it carries ATM addressing, QoS, and bearer correlation information (eecid) that could be exploited to hijack or redirect ATM bearer connections. The document defers to the security mechanisms of the overlying protocol (Megaco, SIP, MGCP) for SDP protection.

security

wire-format §5.3

An NSAP address is encoded as a string of 40 hex digits with dots after the 2nd, 6th, 10th, 14th, 18th, 22nd, 26th, 30th, 34th and 38th digits; no '0x' prefix is used. An E164 address is a decimal number of up to 15 digits. A GWID/ALIAS address is a variable-length alphanumeric string of up to 32 characters.

wire-format §5.6.1.1

The 'eecid' attribute value consists of up to 8 hex digits (equivalent to 4 octets) with no '0x' prefix, since it is always hexadecimal. Hex digits to the left are more significant. Syntax: a=eecid:<eecid>.

wire-format §5.5.1

The VPI field is 8 or 12 bits; the VCI field is 16 bits; the CID (Channel Identifier) field is 8 bits. The VPCI is a 16-bit field that retains its value across VP crossconnects. The VCCI is a 16-bit field that retains its value across VC crossconnects. All may be expressed in decimal or hex (with '0x' prefix for hex).