Realm-Based Packet Marking
The Oracle Communications Session Border Controller supports TOS/DiffServ functions that allow you to
- Set up realm-based packet marking by media type, either audio-voice or video
- Set up realm-based packet marking for signaling, either SIP or H.323
Upstream devices use these markings to classify traffic in order to determine the priority level of treatment it will receive.
By default, the SBC does not pass DSCP codes in ingress packets to egress packets. You must configure a media-policy with desired TOS changes and affix those policies to the realms on which you want to define egress types of service. Without amedia-policy, the SBC includes the default DSCP code, CS0 (Hex 0x00), as the DSCP code to all egress media packets.
About TOS DiffServ
TOS and DiffServ are two different mechanisms used to achieve QoS in enterprise and service provider networks; they are two different ways of marking traffic to indicate its priority to upstream devices in the network.
For more information about TOS (packet) marking, refer to:
- IETF RFC 1349 (http://www.ietf.org/rfc/rfc1349.txt)
For more information about DiffServ, refer to:
- IETF RFC 2474 (http://www.ietf.org/rfc/rfc2474.txt)
- IETF RFC 2475 (http://www.ietf.org/rfc/rfc2475.txt).
ToS Byte
The TOS byte format is as follows:
The TOS byte is broken down into three components:
- Precedence—The most used component of the TOS byte, the precedence component is defined by three bits. There are eight possible precedence values ranging from 000 (decimal 0) through 111 (decimal 7). Generally, a precedence value of 000 refers to the lowest priority traffic, and a precedence value of 111 refers to the highest priority traffic.
- TOS—The TOS component is defined by four bits, although these bits are rarely used.
- MBZ—The must be zero (MBZ) component of the TOS byte is never used.
DiffServ Byte
Given that the TOS byte was rarely used, the IETF redefined it and in doing so created the DiffServ byte.
The DiffServ byte format is as follows:
The DiffServ codepoint value is six bits long, compared to the three-bit-long TOS byte’s precedence component. Given the increased bit length, DiffServ codepoints can range from 000000 (decimal 0) to 111111 (decimal 63).
Note:
By default, DiffServ codepoint mappings map exactly to the precedence component priorities of the original TOS byte specification.Packet Marking for Media
You can set the TOS/DiffServ values that define an individual type or class of service for a given realm. In addition, you can specify:
- One or more audio media types for SIP and/or H.323
- One or more video media types for SIP and/or H.323
- Both audio and video media types for SIP and/or H.323
For all incoming SIP and H.23 requests, the media type is determined by negotiation or by preferred codec. SIP media types are determined by the SDP, and H.323 media types are determined by the media specification transmitted during call setup.
Configuring Packet Marking by Media Type
This section describes how to set up the media policy configuration that you need for this feature, and then how to apply it to a realm.
These are the ACLI parameters that you set for the media policy:
name media policy name
tos-settings list of TOS settingsNote:
The media-policy, tos-settings parameter is not RTC supported and a reboot is required for these updates to take affect.This is the ACLI parameter that you set for the realm:
media-policy default media policy nameSignaling Packet Marking Configuration
ToS marking for signaling requires you to configure a media policy and set the name of the media policy in the appropriate realm configuration.
This section shows you how to configure packet marking for signaling.
Using Class Profile for Packet Marking
Class profile provides an additional means of ToS marking, but only for limited circumstances. Use class-profile only if you are marking ToS on traffic destined for a specific To address, and when media-policy is not used on the same realm. Using media-policy for ToS marking is, by far, more common.
To configure a class profile, you prepare your desired media policy, create the class profile referencing the media policy and the To address, and set the name of the class profile in the appropriate realm configuration.
Differentiated Services for DNS and ENUM
The Oracle Communications Session Border Controller can mark DNS/ENUM packets with a configurable differentiated services code point (DSCP).
Certain service providers mandate support for Differentiated Services (DS) on all traffic streams exiting any network element. This mandate requires that network elements function as a DS marker — that is as a device that sets the Distributed Services Codepoint (DSCP) in the Differentiated Services field of the IP header.
Previous software releases provided the capabilities to mark standard SIP and Real-Time Protocol (RTP) messages. Release S-CX6.4.0M3 adds the capability to mark DNS and ENUM queries.
For basic information about DS, refer to:
-
The ACLI Configuration Guide Realm-Based Packet Marking topic in the Realms and Nested Realms chapter, which provides information on currently supported DS marking of SIP and RTP packets
-
IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers (http://www.ietf.org/rfc/rfc2474.txt)
-
IETF RFC 2475, An Architecture for Differentiated Services (http://www.ietf.org/rfc/rfc2475.txt).
DS provides a mechanism to define and deliver multiple and unique service classifications that can be offered by a service provider. Specific service classifications are identified by a DSCP, essentially a numeric index. The DSCP maps to a per-hop-behavior (PHB) that defines an associated service class. PHBs are generally defined in terms of call admission controls, packet drop criteria, and queue admission algorithms. In theory, DS supports 64 distinct classifications. In practice, however, network offerings generally consist of a much smaller suite, which typically includes:
- Default PHB - required best effort service — defined in RFC 2474
- Expedited Forwarding (EF) PHB - low-loss, low-latency — defined in RFC 3246, An Expedited Forwarding PHB
- Assured Forwarding (AF) PHB - assured delivery within subscriber limits — defined in RFC 2597, Assured Forwarding PHB Group, and RFC 3260, New Terminology and Clarifications for Diffserv
- Class Selector PHBs - maintain compatibility with previous TOS (type of service) precedence usage — defined in RFC 2474
Marking of DNS and ENUM queries requires the creation of a Differentiated Services media policy, and the assignment of such a policy to a specific realm.