Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
A call server receives a request from a user to make a call. In order for acceptable service to be provided, admission control, resource reservation, and packet marking must occur, and accounting must be turned on for billing purposes. The call server may not directly control all of the network elements that perform these functions, but authorizes them to perform these functions on behalf of the caller. This authorization must be communicated somehow to the network element(s) before the call can be established.
In the Cable Labs packet cable standard, the call management server (CMS)/ gate controller performs the dual role of call server + policy decision point (PDP). The architecture looks like the following (only the control connections are shown):
An abbreviated call flow 1 is as follows:
1.
Originating terminal notifies CMS of offhook event, digits dialed
2.
CMS notifies originating terminal to establish connection, originating terminal sends SDP profile back
3.
CMS notifies destination CMTS to establish a gate, CMTS acknowledges
4.
CMS notifies destination terminal to establish a connection, destination terminal sends SDP profile back
5.
Destination terminal requests resources, destination CMTS grants the terminal’s request
6.
Destination terminal notifies the CMS it is provisioned
7.
CMS notifies originating CMTS to establish a gate, CMTS acknowledges
8.
CMS notifies originating terminal to modify the connection
9.
Originating terminal requests resources from originating CMTS, originating CMTS grants the request
10.
Originating terminal notifies CMS it is provisioned, ready to proceed
11.
Backbone provisioning occurs, ringing begins, ….
1 Cable Television Labs, “Packetcable Architecture Call Flows Technical Report”, PKT-TR-CF-ON-ON-V01-
991201, http://www.packetcable.com/specs/pkt-tr-cf-on-on-v01-991201.pdf, December 1999.
-1-

Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
The packet cable model requires a close relationship between the call server and the access network, and between the user terminal and the access network (no support for mobility, only one policy enforcement point). These restrictive assumptions are unattractive for other technologies and business relationships.
We recommend use of the push sequence for the general task of integrating call authorization and resource reservation. Assume the following model:
The sequence of events in this model is as follows.
1.
Originating terminal notifies CMS of offhook event, digits dialed
2.
CMS notifies originating terminal to establish connection, originating terminal sends SDP profile back
3.
CMS authorizes the destination CMTS to establish a gate, and sends this authorization to the destination terminal
4.
CMS notifies destination terminal to establish a connection, destination terminal sends SDP profile back
5.
Destination terminal requests resources, along with the authorization to establish a gate from the
CMS.
6.
Destination CMTS requests permission from the policy server to allocate resources, policy server replies with permission.
7.
Destination CMTS grants the destination terminal’s request
8.
Destination terminal notifies the CMS it is provisioned
9.
CMS authorizes the originating CMTS to establish a gate, and sends this authorization to the originating terminal
10.
CMS notifies originating terminal to modify the connection
11.
Originating terminal requests resources, along with the authorization to establish a gate from the CMS
12.
Originating CMTS requests permission from the policy server to allocate resources, policy server replies with permission.
-2-

Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
13.
Originating CMTS grants the originating terminal’s request
14.
Originating terminal notifies CMS it is provisioned, ready to proceed
15.
Backbone provisioning occurs, ringing begins, ….
The model above effectively decouples resource policy and call service, so that there can be two independent sources of control of the network resources: the call server, and the policy server.
The model above does not require direct communication between the call server and the policy server, or between the call server and the routers. This means the call server can be completely oblivious to the topology of the originating and destination networks. It also allows the user to move around in the access network. The only static association is between the policy server and the devices or routers it controls.
Theft of service is prevented in the packet cable model through the use of gates that the call server installs in the originating and destination CMTSs. In the push model, the authorization from the call server is in effect a “gate” that is presented to the CMTS by the terminal on behalf of the call server, rather than directly installed into the CMTS by the call server. The authorization can contain the same parameters as the packet cable gate 2 (Gate-ID, Classifier, flags, Authorized FlowSpec, Reserved FlowSpec), as well as a timestamp, good-until date, and authentication information to prove the ticket was issued by the CMS. This authorization is referred to from now on as a “media authorization object”.
This model requires a means for a terminal to request resources and get a response from the CMTS, and a means for the CMTS to communicate with the policy server. Existing IETF protocols that serve these purposes are RSVP and COPS, respectively.
The “media authorization object” would have to be added to messages between the call server and the terminals (exactly what messages depends on the whether SIP, H.323, or H.248 is used for call signaling).
The “media authorization object” would have to be defined for RSVP PATH and RESV messages. If it is desirable for edge devices to be oblivious to call servers, then the “media authorization object” will have to be sent to the policy server (i.e., added to a COPS message), which would know how to interpret the “media authorization object”.
An additional protection against theft of service can be provided if the CMS only communicated partial gate information to the originating terminal, which then passed it on to the policy server via the edge router. The authorization object would contain the IP address of the CMS, which the policy server could then directly contact to get the complete gate information. For an additional set of message exchanges, this would buy an additional level of protection.
If a “media authorization object” is to be forwarded by a user terminal, it must not be possible for the terminal to forge, modify, or reuse the object.
2 Cable Television Labs, “Packetcable Dynamic Quality-of-Service Specification”, PKT-SP-DQOS-I01-991201, http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf, December 1999.
-3-

Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
To prevent forgery or modification, the object can be digitally signed (encrypted message digest) by the issuer (the call server). The choices of technologies include the following:
1.
Public key infrastructure. Any router or policy server can obtain the public key of the issuer at any time, with no preexisting relationship required. Only the certificate authority (CA) needs to know everybody and share a key with everybody. Greatest flexibility, but most expensive to compute, operate, and maintain.
2.
Ticket-granting servers, a la Kerberos. Less expensive to compute and maintain. The TGS needs to share a key with all participants. The issuer of the media authorization needs to ask for tickets for specific routers or policy servers, which seems to defeat the purpose of using authorization objects in the first place.
3.
Shared secrets. Least expensive to use. Call servers are assumed to encrypt using a key known to any routers / policy servers in the domain they control for this call. Does not require the issuer of authorization to know specifically which routers or policy servers will be contacted, but does require it to use a key known by them.
To prevent reuse of a media authorization object, it must include a randomly generated ID number. In addition, to limit the duration of usage for the object, there should be a time-stamp that limits the time until the object is first presented. Use of a time-stamp would require some degree of synchronization (on the order of minutes) between call servers and policy servers.
The relationship of "authorization" and "billing" needs to be clarified. Suppose we use as an example a long distance call initiated in Raleigh by a Bellsouth subscriber, carried long distance by MCI, and destined for a
Bell Canada subscriber in Toronto. Imagine there are SIP proxies for each of the 3 networks. The Raleigh user is paying for the call. Does that mean the Bellsouth proxy can authorize resource reservation in the MCI and Bell Canada networks? Or does each proxy authorize resource usage in its network, even though the
Bellsouth subscriber is paying?
If resource reservation is end-to-end, but resource authorization is domain-specific, there may be a problem with carrying a single authorization object in the RSVP message. In this case, the choices are:
1.
Insert multiple authorizations in the RSVP messages, which can be examined by routers to find an authorization appropriate for its domain, or
2.
Allow the proxy to directly contact the policy server with authorization information, as in the draft “SIP
Extensions for Media Authorization” . In this model, each call server must know which policy server(s) to contact, and there is no need to insert a media authorization object in the resource reservation messages.
3
If resource reservation is "segmented" (packetcable term meaning RSVP messages only traverse a single domain) and authorization is domain-specific, there is no problem with having a single authorization in the
RSVP message. On the other hand, if resource reservation is segmented (domain-specific), how do call servers communicate with each other the state of their resource reservations? There does not seem to be any clear standard yet defined for this purpose.
If resource reservation is end-to-end and authorization is by a single proxy, there is no problem.
An edge router generates a request to a policy server (policy decision point, or PDP) when it receives an RSVP
Path or Resv message. This request should contain the “media authorization object” provided to the terminal by the Call Server. The object must first have been communicated to the terminal by the call server.
3 W. Marshall et al., “SIP Extensions for Media Authorization”, http://www.ietf.org/internet-drafts/draftdcsgroup-sip-call-auth-02.txt, June 2000.
-4-

Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
The draft “Interdomain IP Communications with QoS, Authorization, and Usage Reporting” 4 describes such other functions as notifying the billing server of the start and stop of service, and checking with a clearing house whether the networks being connected have an agreement to carry each other’s traffic, using the Open
Settlement Protocol. These operations are not described in this document.
Latency in call setup is a key issue. The two aspects of latency are message transmission time (number of round trips) and call processing time and load. For each option shown below we will discuss the latency requirements.
In the carrier network, a policy server could become a bottleneck, since it is potentially responding to several messages per router per call. To reduce this overhead, it is possible to migrate call-level policy decisions to the routers, by authorizing a large “chunk” of resources initially. When the utilization of these resources exceeds a threshold, the router would then contact the policy server for authorization to increment the resource level by another large “chunk”. The policy server in this case would not need to interact with the routers for individual calls.
The following diagram indicates the callflow for a generic (non-Packetcable) IP network that uses SIP for call signaling, end-to-end RSVP for resource reservation, and COPS for policy enforcement. This callflow is based primarily on the documents “Architectural Considerations for Providing Carrier Class Telephony Services
Utilizing SIP-Based Distributed Call Control Mechanisms” 5 , “Interdomain IP Communications with QoS,
Authorization, and Usage Reporting” and “Integration of Resource Management and SIP for IP Telephony” 6 .
Notes on the callflow can be found at the end of this document.
In this diagram, SIP messages are shown in red, RSVP messages are in blue, and COPS messages are in green.
Messages whose label is contained within a purple border must include the “media authorization object” or gate, created by the SIP proxy. In the case where there are two proxies involved, as shown, it remains to be determined whether there are two authorization objects (one for each proxy), or simply one.
The time to establish the call is 5 round trip times from terminal to terminal, plus 4 roundtrip times from a router to a policy server. This includes one extra round trip time; as proposed in the draft “Integration of
Resource Management and SIP for IP Telephony” the satisfactory establishment of QoS conditions is signaled at the SIP layer using a “Precondition-Met” (or “Comet”) message from the originator to the destination, followed by a “200 OK” response.
4 H. Sinnreich et al., “Interdomain IP Communications with QoS, Authorization, and Usage Reporting”, IETF
Draft http://www.softarmor.com/sipwg/drafts/draft-sinnreich-sip-qos-osp-01.txt, February 2000.
5 W. Marshall et al., “Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-
Based Distributed Call Control Mechanisms”, http://www.ietf.org/internet-drafts/draft-dcsgroup-sip-arch-
02.txt, June 2000.
6 W. Marshall et al., “Integration of Resource Management and SIP for IP Telephony”, IETF Draft http://www.ietf.org/internet-drafts/draft-manyfolks-sip-resource-01.txt, June 2000.
-5-

Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
-6-

Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
The NCS call flows are taken from the documents “Packetcable Dynamic Quality-of-Service Specification”
(particularly Appendix I: “Sample Protocol Message Exchanges for Basic NCS Call for Embedded MTA”) and
7
“Packetcable Architecture Call Flows Technical Report” 8 .
Docsis signals are shown in yellow-brown, SIP in red, NCS in purple, and DQOS in pale blue. The DQOS “gate set – gate open – gate close” signals are shown being replaced in (eliminated from) this model by appending the “media authorization object” directly to the Docsis signals. The media authorization objects are relayed in the NCS (MGCP) CRCX – MDCX – DLCX signals from the call server to the MTA. Resource reservation (via
Docsis DSA, DSC, and DSD messages) is segmented, so each call server authorizes resources in its specific domain. The message conveying readiness between the call servers is labeled with question marks, indicating my uncertainty about which message type would serve this purpose.
The latency of this modified Packetcable approach is 2 round-trip times from MTA to MTA, plus 4 ½ roundtrip times from the MTA to the CMTS.
7 Cable Television Labs, “Packetcable Dynamic Quality-of-Service Specification”, PKT-SP-DQOS-I01-991201, http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf, December 1999.
8 Cable Television Labs, “Packetcable Architecture Call Flows Technical Report”, PKT-TR-CF-ON-ON-V01-
991201, http://www.packetcable.com/specs/pkt-tr-cf-on-on-v01-991201.pdf, December 1999.
-7-

Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
SIP Invite and 183 messages would have to be extended with a new object, the media authorization object.
Alternatively, the media authorization object could be placed in the SDP message, which is encapsulated by many other protocols, and therefore would not require changes to those protocols. RSVP Path messages and
COPS REQ messages would likewise have to be extended with a new object type. All of these message types are extensible and allow definition of new options or objects.
-8-

Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
The Internet Draft “Identity Representation for RSVP” 9 describes a mechanism for inserting authorization objects in RSVP messages. The authorization objects that are defined are only the User ID and the
Application ID at present, but similar ideas could be used for inserting media authorization objects. This draft suggests only the use of Kerberos or PKI (not shared secrets), and does authentication on a hop-by-hop basis, rather than end-to-end.
Wireless IP networks that are data centric are likely to incorporate the standard elements of other IP networks, including policy servers and enforcement points, COPS, RSVP, etc., pushed as far out to the edge as possible. For this case the proposed approach seems compatible, and the flexibility of the approach has advantages for mobility.
GPRS/UMTS has created a “core” network that is part of the wireless infrastructure. This core network is packet-based but not consistent with or conformant to IETF protocols in many cases. Therefore, at present any proposal is likely to have not much impact on this “core” network functionality. However, we are providing a capability that eventually will interoperate with UMTS products. Note that finding the “edge device” for a UMTS terminal is not difficult, since routing to the IP address assigned to a mobile terminal can only be accomplished through a specific GGSN (i.e., one GGSN “owns” a block of IP addresses).
There are multiple ways for a terminal to “find” routers (particularly the edge or access router) along the path to the destination. If RSVP is used for resource reservation, the edge router is found by whatever normal routing protocol is built into the access network. There is no need, nor is it desirable, for the terminal to use something besides the routing protocol to discover these routers, since then RSVP would become a hop-by-hop protocol rather than an end-to-end protocol.
In the cable environment, resource reservation is handled using DOCSIS signaling (DSA, DSC, and DSD) and coordinated with call signaling in the DQOS standard.
For Ethernet LANS, a method of resource reservation that is integrated with RSVP signaling is described in the
Internet standards RFC2814 10 , RFC2815 11 , and RFC2816 12 .
9 S. Yadav et al., “Identity Representation for RSVP”, Internet Draft, http://search.ietf.org/internetdrafts/draft-ietf-rap-rsvp-newidentity-00.txt, June 2000.
10 R. Yavatkar et al., “SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over
IEEE 802-style networks”, http://www.ietf.org/rfc/rfc2814.txt, May 2000.
11 M. Seaman et al., “Integrated Service Mappings on IEEE 802 Networks”, http://www.ietf.org/rfc/rfc2815.txt, May 2000.
12 A. Ghanwani et al., “A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN
Technologies”, http://www.ietf.org/rfc/rfc2816.txt, May 2000.
-9-

Douglas Reeves
Nortel Networks / N.C. State University
4/15/20
Notes on “Call Flows: SIP + End-to-End RSVP + COPS (modifications to the DCS proposed standards)”
(Omitting the steps of the off-hook event, dial plan loading, notify commands, etc.)
A number is dialed and recognized according to the dial plan. The SIP client initiates an INVITE message to the “local” SIP proxy. This proxy checks the subscriber database to authenticate the user’s ID and ability to receive (and be billed for) the requested service. If successful, the proxy forwards the invitation onwards towards the intended destination. As part of the forwarded invitation, the proxy appends the “media authorization object”, or MAO, that authorizes the service and the resources necessary to provide that service. As part of the MAO, the proxy includes its own identity, and authenticates the information it contains.
1.
The invitation is forwarded without modification to the destination. The destination responds favorably with a “session response” (183) message describing its preferences . Either the destination user agent can append the MAO to this message, or the destination SIP proxy can append it; in the diagram, the proxy does this. The session response message is sent back to the originator. At this point, both the originator and the destination have received the MAO information.
2.
(The use of the PRACK / 200 OK is optional and will not be discussed further. It is included in the diagram essentially for conformance with other example call flows, but we regard its uses as optional.)
3.
RSVP is initiated by the orginator to reserve resources on the path from the originator to the destination. The first message is a PATH message, which includes the MAO. This message is received by the edge or access router that is first reached by the originating terminal. This router forwards the request to its policy server, including the MAO, using COPS. In this illustration, it is assumed the policy server agrees to the request, after verifying (using the MAO) that the request is properly authorized. The policy server responds favorably to the edge router.
4.
The edge router then forwards the PATH message onwards. It encounters the edge or access router for the destination, which forwards it (as a COPS request) to its policy server, with the MAO. The destination policy server responds favorably. The PATH message is propagated onwards to the destination.
5.
Although on the diagram I have indicated the MAO being transported backwards in the RESV message, this may not be necessary. Since the policy decision has been made, based on the MAO, already, it does not seem necessary to include it in the RESV message unless it is deemed to be a desirable extra level of security. At any rate, the RESV message traverses the network backwards to the originator, and resources are reserved along the path. The RESVCONF message completes the handshake so that all parties are aware of successful completion.
6.
The last 3 steps are repeated, at the same time, but in the direction from the destination to the originator, and back again. This establishes the media path in both directions so that a 2-way conversation can be held.
7.
In our illustration, what follows does not involve the use of the MAO, which is only used for call setup.
That is, resource reservation is confirmed, ringing is applied, the session is established and held for the duration of the conversation, one party hangs up, the resources are reclaimed, and the other party hangs up. It is possible that the MAO should be used also to authorize the reclamation of resources (the PATHTEAR message), again, for security reasons. This issue remains to be investigated.
-10-