Internet Draft Francois Le Faucheur Bruce Thompson Cisco Systems, Inc. Angela Chiu AT&T Internet Draft Expires: September 2000 Document: draft-lefaucheur-vompls-bearer-cont-00.txt, March, 2000 Bearer Control for VoIP and VoMPLS Control Plane Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are Working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as _work in progress._ The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Control Plane for IP based public Voice services comprises Call Control and Bearer Control. This document focuses on the Bearer Control aspects of the Voice over MPLS Framework. First we propose a more generic Reference Model for the VoMPLS Framework which covers environments with any mix of MPLS and non-MPLS transport. Le Faucheur, et. al 1 Bearer Control for VoIP & VoMPLS March 2000 Then we review several existing items of work in the IETF pertaining to Bearer Control for VoIP and point out their direct applicability to VoMPLS. Lastly we describe one scalable approach for achieving MPLS benefits, such as Constraint Based Routing and Fast Reroute, with only aggregate MPLS processing in the core. The authors finally offer recommendations to reflect these considerations into the VoMPLS Framework. 1. Introduction [VOMPLS] proposes a framework for using MPLS as the underlying technology for transporting IP based public voice services. The Control Plane for such IP based public Voice services over a packet infrastructure comprises Call Control and Bearer Control. This document focuses on the Bearer Control and associated QoS aspects. We focus on environments where guaranteed QoS and ability to perform call admission control are required. We focus on intra-domain Bearer Control. Bearer control across multiple administrative domains is inherently more complex where both technical issues and policy issues need to be addressed in an integrated manner. We expect many concepts described in this document to be extendable to the inter-domain case, which we leave for future study. The purpose of this draft is to offer some recommendations for progressing the VoMPLS Framework. This document describes refinements to the VoMPLS Framework and Reference Model that allow it to take advantage of, and inter-operate with, existing standards for VoIP based QoS Bearer Control. It is viewed that most networks in which VoMPLS is deployed will include VoIP endpoints as well as VoMPLS endpoints. These networks may also include an MPLS core for transport of VoIP and non-voice traffic. The likely presence of VoIP endpoints and VoMPLS endpoints in a heterogeneous network introduces the requirement of an inter-working function between IP and MPLS based QoS services. This document describes refinements to the VoMPLS Framework and Reference Model to include an IP/MPLS inter-working function as part of the reference architecture. This refinement allows a VoMPLS endpoint to be described in terms of a VoIP endpoint with an internal IP/MPLS inter- working function. Describing a VoMPLS endpoint in this way Le Faucheur et. al 2 Bearer Control for VoIP & VoMPLS March 2000 assures that it will be able to coexist and inter-operate with existing VoIP endpoints and existing native IP transport networks. 2. VoIP/VoMPLS Reference Model 2.1 Current Reference Model The current VoMPLS reference model described in [VoMPLS] includes functional elements called Media Gateways (MG) and Signaling Gateways (SG). These functional elements respectively perform inter-working between the user plane (bearer) and the signaling plane of the PSTN and an MPLS network. The reference model also describes specific instantiations of a media gateway when connected to different PSTN interfaces. These instantiations include a Trunk Gateway, an Access gateway, a Line Side Gateway, and an Integrated Access Device. All of these instantiations should have the same interfaces defined for connection to the MPLS network. 2.2 Proposed Reference Model 2.2.1 Media and Signaling Inter-Working Function We propose further refining the definition of a MG and a SG to include a PSTN to IP inter-working function and an IP to MPLS inter-working function. The PSTN to IP inter-working function can be called a Media Gateway (MG) for bearer connections and a Signaling Gateway (SG) for signaling connections as it is in the current Reference Model. Instead of generating MPLS packets, the MG and SG generate VoIP packets. Specific instantiations of the MG still use the same naming convention as the current Reference Model. The IP to MPLS inter-working function is done with a separate functional element called the Inter-Working Function. A separate Inter-Working Function is defined for Media Gateways and Signaling Gateways. The Inter-Working Function for Media Gateways is called the Media Inter- Working Function (MIWF). The Inter-Working Function for Signaling Gateways is called the Signaling Inter-Working Function (SIWF). This split in functional elements is shown below in the modified Reference Model of Figure 1. Le Faucheur et. al 3 Bearer Control for VoIP & VoMPLS March 2000 +--+ +------------+ +------+(*)+--+ +---------------------+ |CA|-| |<->| MIWF |<->|TG|<->| | +--+ | | +------+ +--+ | | | IP/MPLS | +------+(#)+--+ | Circuit-Switched | +--+ | Network |<->| SIWF |<->|SG|<->| Network (e.g. PSTN)| |CA|-| | +------+ +--+ | | +--+ | | | | +------------+ +---------------------+ ^ ^ +---+ | | | +------+(*)|AG/| +---+ | +>| MIWF |<->|IAD|<-+ |LSG| | +------+ +---+ | +---+ | | | (*) | | +----+ | | |MIWF| | | +----+ | | | | | +-------+ | | |IP/MPLS| | | |Network| | | +-------+ | | | | | +----+ | | |MIWF| | | +----+ | | | (*) | | +---+ | | |AG/| | | |IAD| | | +---+ | | | IP Terminals Conventional Terminals (e.g. Workstation-phone, (e.g. PABX, Analog Phone, Key IP_PBX) System, ISDN TE, VF modem, FAX) Figure 1 Voice over MPLS Reference Model (*) The MG (TG, AG/IAD, LSG) and MIWF may be: - implemented in the same physical device in the case of a VoMPLS MG. - implemented as separate devices in the case of a VoIP MG. The MG and MIWF are then connected via an IP internetwork. (#) The SG and SIWF may be: - implemented in the same physical device in the case of a VoMPLS SG. - implemented as separate devices in the case of a VoIP SG. The SG and SIWF are then connected via an IP internetwork. Le Faucheur et. al 4 Bearer Control for VoIP & VoMPLS March 2000 2.2.2 Media Gateways A Media Gateway is responsible for inter-working between various PSTN bearer types and VoIP. VoIP bearer encapsulation using RTP is described in RFCs 1889 and 1890. IP Qos bearer control works as described in Section 3 of this draft. Instantiations of the MG include the Trunking Gateway (TG), an Access Gateway (AG), a Line Side Gateway (LSG), and an Integrated Access Device (IAD). 2.2.3 Media Inter-Working Function The Media Inter-Working Function (MIWF) may be implemented in the same functional element as the Media Gateway, or it may be implemented as a separate functional element interconnected to the Media Gateway via an IP internetwork. The MIWF implements the functionality of an MPLS Edge Node [MPLS_ARCH]. It also performs inter-working between VoIP QoS bearer control and MPLS based QoS services. Where Diff-Serv mechanisms are used for the IP Bearer QoS, interworking with MPLS is specified in [MPLS_DIFF]. Where QoS reservations are used through RSVP signaling, interworking with MPLS could be achieved in two modes: - without aggregation: one RSVP reservation maps to an MPLS LSP. Such interworking had been specified in [MPLS_RSVP]. This document has since expired, since the corresponding work item was not on the priority list of the MPLS Working Group, but it may be resubmitted. - with aggregation: multiple RSVP reservations maps into a shared MPLS LSP. Such interworking is discussed further below in section 5 and combines operations of RSVP Aggregation [RSVP_AGG] with the RSVP extensions for LSP set-up [RSVP-TE]. 2.2.4 Signaling Gateways A Signaling Gateway is responsible for terminating link layer signaling protocols for PSTN networks that carry signaling and bearer on separate physical links. SS7 signaling is an example of signaling carried on separate physical links in the PSTN. The packet side of a SG generates signaling messages destined for the CA using IP as a transport and SCTP [SCTP] as a reliable signaling transport protocol. Depending upon the signaling protocol being transported, an appropriate adaptation layer will be used to implement layer specific aspects of the signaling Le Faucheur et. al 5 Bearer Control for VoIP & VoMPLS March 2000 protocol. For SS7 signaling transport, the SS7 MTP2-User Adaptation Layer [SS7 UAL] should be used. For ISDN signaling transport, the ISDN Q.921-User Adaptation Layer [ISDN UAL] should be used. 2.2.5 Signaling Inter-Working Function The SIWF may be implemented in the same functional element as the Signaling Gateway, or it may be implemented as a separate functional element interconnected to the Signaling Gateway via an IP internetwork. The Signaling Inter-Working Function implements the functionality of an MPLS Edge Node [MPLS_ARCH]. Where Diff-Serv mechanisms are used for the transport of signaling, interworking with MPLS is specified in [MPLS_DIFF]. 2.2.6 Other Functional Elements Descriptions of other functional elements remain as they are in the current VoMPLS reference model. 2.2.7 VoMPLS Media Gateway A VoMPLS Media Gateway is an implementation of a Media Gateway and a Media Inter-Working Function in a single functional element. An implementation of a VoMPLS Media Gateway is not required to implement the protocols defined between the Media Gateway and the Media Inter-Working Function. A VoMPLS Media Gateway is required to implement the functionality of the Media Gateway and the Media Inter- Working Function. 2.2.8 VoMPLS Signaling Gateway A VoMPLS Signaling Gateway is an implementation of a Signaling Gateway and a Signaling Inter-Working Function in a single functional element. An implementation of a VoMPLS Signaling Gateway is not required to implement the protocols defined between the Signaling Gateway and the Signaling Inter-Working Function. A VoMPLS Signaling Gateway is required to implement the functionality of the Signaling Gateway and the Signaling Inter-Working Function. 3. Bearer Control with VoIP The Control Plane involved in VoIP and VoMPLS can be divided into two components: - the Call Control Le Faucheur et. al 6 Bearer Control for VoIP & VoMPLS March 2000 - the Bearer Control The Call Control is responsible for establishing, modifying and releasing telephony calls. Entities involved in Call Control may be communicating with protocols such as Q.BICC, SIP, or H.323. In the `decomposed gateway model', Call Agents involved in the Call Control control the Gateways (GWs) via media gateway protocols such as MGCP or Megaco/H.248. The Bearer Control is responsible for establishing, modifying and releasing the logical connection between Gateways. 3.1 Concept of IP QoS Bearer Control When telephony services are transported over TDM or natively over layer 2 technologies such as ATM, the `bearer' is indeed a circuit or a logical connection. Thus with such transport technologies, no connectivity is available until the bearer is established. Also, all the connectivity attributes such as quality of service and resource reservations are established simultaneously with the bearer itself. Thus, in such environments Bearer Control is typically an atomic action establishing at the same time connectivity as well as all the connectivity attributes (eg QoS). When telephony services are transported over IP, the concept of bearer is perhaps less intuitive since default connectivity between Gateways is permanently available without requiring any explicit bearer establishment. Because default connectivity is permanently available, it has sometimes been incorrectly assumed that the concept of Bearer Control did not apply to VoIP. Where the default connectivity between Gateways is appropriate for transport of the telephony services, the Bearer Control role indeed reduces to nothing. However, the default connectivity can not always be assumed to be sufficient. We focus on environments where the service provider wants to guarantee adequate quality to (all or some) voice calls and thus wants to be able to reserve resources and obtain Quality of Service above those always available through default connectivity. This resource reservation and QoS properties (above and beyond the default connectivity) need to be explicitly established by the Bearer Control entity. We propose to refer to this resource reservation and QoS establishment as the `IP QoS Bearer Control'. Le Faucheur et. al 7 Bearer Control for VoIP & VoMPLS March 2000 3.2 Advertisement/Negotiation of Traffic Parameters and IP QoS Bearer Control requirement in Call Control It is necessary for the call control protocol to include provisions for specifying the codec type, packetization period, and other parameters required to determine all the traffic parameters (eg token bucket profile) required for the IP QoS Bearer Control to establish the required reservation and QoS for the call. Existing call control protocols already include such provisions. It is useful for the Call Control protocols to be able to advertise the requirements associated with a given call in terms of `IP QoS Bearer Control' (eg. whether, for each direction, QoS reservation is mandatory, optional or not requested at all) for example in order to support different levels of quality for different calls. It may also be useful for the Call Control protocols to allow negotiation of the `IP QoS Bearer Control' requirements (for example, if one of the party does not want to incur the charges associated with reservations). Ongoing work in the IETF is addressing Call Control protocol capability to advertise/negotiate the `IP QoS Bearer Control' requirements. One example of this is the SDP extensions defined in [SIP_RES] in order to advertise pre-conditions for call establishment in terms of QoS reservation. Because megaco also makes use of SDP, we expect these SDP extensions defined for SIP to be also applicable to megaco. 3.3 Signaling for IP QoS Bearer Control Establishment Once a requirement for `IP QoS Bearer Control' (eg QoS reservation) has been determined through the mechanisms described in section 3.2, the Bearer Control protocol must enter in action. The QoS architecture for the Internet separates QoS signaling from application level signaling [RSVP]. In agreement with [SIP_RES], the authors of this paper feel that such QoS architecture is particularly applicable to support of public telephony services over a packetized infrastructure. This means that the `IP QoS Bearer Control' must remain separate from the Call Control: - `IP QoS Bearer Control' is performed by the Bearer Control entities which are logically separate from the Call Control entities. Le Faucheur et. al 8 Bearer Control for VoIP & VoMPLS March 2000 - `IP QoS Bearer Control' is to be performed through a network level protocol designed for network resource reservation and QoS signaling and which is separate from the Call Control protocol. Benefits of this QoS architecture include: - alignment to natural layering: management of QoS reservations are fundamentally a network layer issue while Call Control entities are fundamentally application level devices (with no or limited natural network awareness) - avoids issues related to difference between bearer path and control path: Call Control entities are often located out of the bearer path which would make it difficult for them to perform QoS reservation on the bearer path. - common `IP QoS Bearer Control' solution for all Call Control: Because the Bearer Control protocol operates separately from the Call Control protocol, the same Bearer Control solution can be used by all the Call Control protocols (eg. SIP, H.323, Q.1901) as well as all the Media Gateway Control protocols (Megaco/H.248, MGCP,). - common `IP QoS Bearer Control' solution for all applications: Because the Bearer Control performs generic QoS reservation which are not specific to the voice application, the same Bearer Control solution can be used by other applications than telephony (eg video, multimedia). The IETF has defined a network level IP signaling protocol [RSVP] as well as QoS services (such as Guaranteed Services [GUARANTEED] and Controlled Load [CONTROLLED]) which can be used as the `IP QoS Bearer Control' to achieve predictable/constrained QoS required for public telephony services over IP. The IETF has also defined a framework [POLICY] and associated protocols (such as [COPS]) for policy based admission control applicable to environments where the resource-based admission control is performed through the RSVP protocol. Thus, where RSVP is used as the IP QoS Bearer Control protocol existing specifications define a way to enforce various policies for controlling resource access. As an example, such policies may be useful at network boundaries. [RSVP_COMP] specifies how RSVP can take into account the compression gains achieved through header compression performed locally on some hops. This allows accurate Le Faucheur et. al 9 Bearer Control for VoIP & VoMPLS March 2000 resource reservations even if different hops perform different compression schemes or no compression at all. 3.3.1. Scaling IP QoS Bearer Control with RSVP Much existing work in the IETF has provided various options to achieve carrier class scalability when RSVP is used as the IP QoS Bearer Control protocol at per-call level between VoIP GWs. The simplest option is to carry the per- call RSVP messages through an IP core network transparently, i.e., each core router does not process the RSVP messages, but simply forwards them to the next hop just as if they were regular IP packets. This approach relies on the core network having enough resources pre- provisioned to carry all calls. Another option is to use Int-Serv over Diff-Serv [INT_DIFF]. The attractiveness of this option is using Diff-Serv classification/scheduling complemented by RSVP signaling in the control plane to perform end-to-end admission control. This achieves considerable scalability improvement via aggregation of classification and scheduling states. In addition to using Diff-Serv classification/scheduling in the user plane for scalability improvement, one can scale further in the control plane via additional aggregation of reservation states by using RSVP reservation aggregation [RSVP_AGG]. [RSVP AGG] specifies how to create aggregate reservations dynamically based on end-to-end per-flow reservations (per-call reservations in the VoIP case), and how to classify traffic for which the aggregate reservation applies. The approach also allows service providers to dynamically adjust the size of the aggregate reservations based on certain local policies and algorithms. Such policies and algorithms may include: 1) increase or decrease the size of the aggregate reservation by a fixed quantity based on the usage level of current reservation e.g., by comparing with some pre- configured upper and lower thresholds; 2) resize the aggregate reservation based on some trend line over certain period of time characterizing the speed of increase or decrease in call volume; 3) determine the size of aggregate reservation based on a priori requirements that may be associated with a particular day in a week and time of day. Also, [RSVP_AGG] allows recursive aggregation so that multiple levels of aggregation may be used if required. Le Faucheur et. al 10 Bearer Control for VoIP & VoMPLS March 2000 Given all the options described above, it shows that RSVP can be used as a scalable Bearer Control protocol for VoIP with predictable/constrained QoS over the connectionless infrastructure. 3.4 Coordination between Call Control and IP QoS Bearer Control One of the functions involved in the `IP QoS Bearer Control' is admission control of the requested reservation. If the network resources required to establish the requested QoS reservation are not available and cannot be reserved at least at one point in the network, the reservation will be rejected. This admission control can be seen as a `network level admission control'. Where consistent high quality voice service is required, as assumed in this document focusing on IP based public Voice services, it is essential that a voice call can be rejected (before the called party's phone even rings) if its quality (or the quality of already established calls) cannot be guaranteed. In other words, it is essential to be able to trade service degradation for service rejection. Consequently, the `network level admission control' must be translated into `voice admission control'. This is to be achieved by proper coordination between the `IP QoS Bearer Control' signaling and the Call Control signaling. Again, there is ongoing work on standardizing such coordination. Design goals for defining this coordination include telephony user expectations of behavior after phone is ringing, minimization of post dial delay, charging aspects, denial of services,... [DCS_ARCH] provides a more detailed discussion on such coordination in the context of the Distributed Call Signaling (DCS) architecture. [SIP_RES] provides an example of how SIP signaling can be coordinated with `IP QoS Bearer Control signaling'. As another example, [H323_RSVP] has been submitted into ITU SG16 defining how H.323 signaling with `Slow Start' can be coordinated with RSVP. 4. Bearer Control for VoMPLS 4.1 Concept of VoMPLS Bearer Control Le Faucheur et. al 11 Bearer Control for VoIP & VoMPLS March 2000 Let's consider a VoMPLS GW i.e. a GW which incorporates both the VoIP function and the IP/MPLS IWU, and thus is capable of transmitting packetised voice over MPLS. Before packetised voice can be transmitted over an MPLS Label Switched Path (LSP), the LSP must be established via a label binding protocol. Since we focus on environments where quality is to be guaranteed to voice calls, the LSP must be established with resource reservation and QoS attributes. The LSP may also be established along a path determined by Constraint Based Routing to meet satisfy these QoS attributes. Also, where Header Compression and multiplexing are performed over the LSP (as allowed by [VOMPLS]), the compression and multiplexing contexts must be established over the LSP. Thus, the VoMPLS Bearer Control function can be seen as responsible for establishment of: - connectivity (possibly with Constraint Based Routing) - QoS and resource reservation - compression/multiplexing context 4.2 VoMPLS Bearer Control for Connectivity RSVP [RSVP-TE] and CR-LDP [CRLDP] can be used as the Bearer Control protocol to perform LSP set-up and corresponding label binding. Where Constraint Based Routing is to be performed at the granularity of GW-to-GW-pair, Constraint Based Routing can be performed at LSP set-up so that RSVP or CR-LDP establish the LSP along the computed path. Where Fast Reroute is to be performed at the granularity of GW-to-GW-pair, Fast Reroute can be requested at LSP set-up by RSVP or CR-LDP. 4.3 VoMPLS Bearer Control for QoS and Resource Reservation Resource reservation and QoS establishment can also be performed by RSVP and CR-LDP. Clearly, they can be performed simultaneously with the LSP establishment (VoMPLS Bearer Control for Connectivity) and can use the same signaling messages simply augmented with the appropriate QoS-related Information Elements. We note that the QoS Bearer Control function for VoMPLS is identical to the IP QoS Bearer Control discussed earlier for VoIP GWs. Consequently, we recommend that all the ongoing work in the IETF pertaining to `IP QoS Bearer Control' for VoIP be recognized by the VoMPLS Framework Le Faucheur et. al 12 Bearer Control for VoIP & VoMPLS March 2000 [VOMPLS] as applicable to VoMPLS and accepted as the common approach. This includes: - solutions for advertisement and negotiation of Traffic Parameters and QoS Bearer Control requirement in Call Control protocols as discussed above in section 3.2. - solutions for QoS Bearer Control signaling as discussed above in section 3.3. - solutions for coordination between call control and QoS bearer Control as discussed above in section 3.4. We recommend that the VoMPLS Framework [VOMPLS] identifies the work required to achieve end-to-end Bearer Control (and in particular end-to-end QoS Bearer Control) in environments mixing MPLS and non-MPLS transport. This includes the interworking functions discussed above in section 2.2.3 for the MIWF. 4.4 VoMPLS Bearer Control for Compression/Multiplexing Establishment of Compression and Multiplexing context is one aspect of VoMPLS Bearer Control. RSVP and CR-LDP may also be used to signal the corresponding information. As an example, details of how RSVP can be used to signal the compression and multiplexing context for the Simple Header Compression are provided in [HDR_COMP]. We note then that all aspects of Bearer Control (connectivity, Constraint Based Routing, QoS and reservation, Compression and Multiplexing) can be performed simultaneously and with the same signaling messages simply carrying Information Elements for all aspects. As mentioned earlier, [RSVP_COMP] specifies how RSVP can take into account the compression gains achieved through header compression performed locally on some hops. This allows accurate resource reservations even if different hops perform different compressions or no compression at all. The approach specified is easily extensible for new compression schemes through the definition of compression identifiers. We recommend that the corresponding compression identifiers be defined for the compression scheme(s) that may be defined for VoMPLS. This will ensure , where RSVP is used as the Bearer Control protocol, that accurate reservations are performed end-to-end even where these VoMPLS compression scheme are used on some hops only (eg. where the LSP does not span the entire GW-to-GW path) and where different compression schemes are used on different logical hops. Le Faucheur et. al 13 Bearer Control for VoIP & VoMPLS March 2000 5. Aggregated MPLS Processing in the Core As discussed above in section 4.2, the VoMPLS Bearer Control entity can establish an MPLS Label Switched Path which can be used to transport one call or, assuming multiplexing is used, to transport all or any subset of the calls between a given pair of GWs. Advanced MPLS features may also be applied onto this LSP such as Constraint Based Routing and protection of the LSP via Fast-Restoration. From the MPLS Control Plane perspective, this results in : - RSVP or CR-LDP signaling processing and label binding at every MPLS hop for each GW-to-GW pair. - resource reservation and admission control at every MPLS hop for each GW-to-GW pair and every time the resource reservation is modified (eg. to adjust to varying number of calls on a GW-to-GW pair) - in case of failure, Fast Reroute at the relevant MPLS hops of all the affected GW-to-GW LSPs From the MPLS user plane perspective, this result in a different MPLS label cross-connect entry in the Label Forwarding Information Base established at every MPLS hop for every GW-to-GW pair. In brief, this involves full MPLS processing at every hop in the MPLS network at the granularity of GW-to-GW pair. As the number of Gateways grow, this may represent a significant scaling burden which would not yield the most cost economical solution in all environments. Consequently, we propose one approach allowing MPLS processing purely on an aggregate basis in the MPLS core. This approach relies on RSVP reservation aggregation as defined in [RSVP_AGG] and already mentioned above in section 3.3.1. Where RSVP is used by GWs as the Bearer Control protocol, the end-to-end GW-to-GW RSVP reservations can be aggregated when entering the aggregation region (ie the core) into a smaller number of fat aggregated reservations within the aggregation region. At the egress of the aggregation region, the aggregated reservations are broken out back into end-to-end GW-to-GW reservations. [RSVP_AGG] specifies that an aggregated reservation may be instantiated as a tunnel of some sort and in particular as an MPLS Tunnel. In this context, we elect to instantiate every aggregate reservation as an MPLS Tunnel. Each MPLS tunnel is then used to transport all the calls associated with the multiple GW-to-GW reservations which are aggregated together through the aggregation region. As defined in [RSVP_AGG], the classification and scheduling Le Faucheur et. al 14 Bearer Control for VoIP & VoMPLS March 2000 required in the core are purely Diff-Serv (as opposed to per-label classification/scheduling), retaining extremely high scalability properties for the user plane in the core. Exactly as in the non-MPLS context discussed in 3.3.1, very flexible and powerful policies and algorithms can be used by the service provider for establishing and controlling the sizing of the aggregated reservations. The MPLS Tunnels corresponding to aggregate reservations can be established via RSVP (or possibly CR-LDP after appropriate mapping is defined). Constraint Based Routing and Fast Restoration can also be applied to these MPLS Tunnels. Both from the MPLS Control Plane perspective as well as from the MPLS User Plane perspective, MPLS processing in the core is now performed at the granularity of the aggregate reservation instead of a the level of GW-to-GW. Yet, the benefits of MPLS such as Constraint Based Routing and Fast Reroute are offered to the transported telephony services; only they are achieved in the core on an aggregate basis. This approach is applicable for aggregation over an MPLS core regardless of whether GWs are connected to the core via MPLS or non-MPLS. For instance, this aggregation can be achieved with VoIP GWs having non-MPLS connectivity to the MPLS core. In that case, a natural (but not mandatory) location to perform the aggregation is at the level of the MIWF ie. the MIWFs also act as Aggregators and Deaggregators as defined in [RSVP_AGG]. Also, this aggregation can be achieved with VoMPLS GWs having full end-to-end MPLS connectivity. In that case, the Aggregators and Deaggregators are MPLS Label Switch Routers located closer into the core than the GWs. The authors recommend that this approach for achieving aggregated MPLS processing in the core be recognized by the VoMPLS Framework [VOMPLS]. 6. Conclusions The authors propose a number of recommendations for progress of the VoMPLS Framework: - that the Reference Model be generalized to cover VoIP as well as VoMPLS. This would clarify that interworking situations involving any mix of MPLS and non-MPLS transport are within the scope of the VoMPLS Framework. This would Le Faucheur et. al 15 Bearer Control for VoIP & VoMPLS March 2000 also clarify that many existing items of work in IETF for VoIP are applicable to VoMPLS. - that the following IETF work on Bearer Control for VoIP be recognized and adopted by the VoMPLS Framework including: * solutions for advertisement and negotiation of Traffic Parameters and QoS Bearer Control requirement in Call Control protocols. * solutions for QoS Bearer Control signaling. * solutions for coordination between call control and QoS bearer Control. - that the VoMPLS Framework recognizes the proposed approach for achieving aggregated MPLS processing in the core. 7. Security Considerations Security Considerations will be discussed in subsequent contributions. 8. Acknowledgments This document has benefited from discussions with Maurice Duault from Cisco Systems. 9. References [VOMPLS] draft-kankkunen-vompls-fw-00.txt, ` Voice over MPLS Framework' [SIP_RES] draft-manyfolks-sip-resource-00.txt, `Integration of Resource Management and SIP for IP Telephony', March 2000 [DCS_ARCH] draft-dscgroup-sip-arch-01.txt, `Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms', March 2000 [HDR_COMP] draft-swallow-mpls-simple-hdr-compress-00.txt, Simple Header Compression, Swallow et al., March 2000 [RSVP] RFC2205, `Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification', Braden et al., September 1997. Le Faucheur et. al 16 Bearer Control for VoIP & VoMPLS March 2000 [GUARANTEED] RFC2212, `Specification of Guaranteed Quality of Service', Shenker et al, September 1997. [CONTROLLED] RFC2211, `Specification of the Controlled-Load Network Element Service', Wroclawski, September 1997. [POLICY] RFC2753, `A Framework for Policy-based Admission Control', Yavatkar et al. , January 2000. [COPS] RFC2748, `The COPS (Common Open Policy Service) Protocol', Durham et al., January 2000. [RSVP_COMP] draft-ietf-intserv-compress-02.txt, `Integrated Services in the Presence of Compressible Flows', Davie et al. , February 2000. [INT_DIFF] draft-ietf-issll-diffserv-rsvp-04.txt, `A Framework For Integrated Services Operation Over Diffserv Networks', Bernet et al., March 2000. [RSVP_AGG] draft-ietf-issll-rsvp-aggr-02.txt, `Aggregation of RSVP for IPv4 and IPv6 Reservations', Baker et al., March 2000. [RSVP-TE] Awduche et al, draft-ietf-mpls-rsvp-lsp-tunnel- 05.txt, "RSVP-TE: Extensions to RSVP for LSP Tunnels", February 2000. [CR-LDP] Jamoussi et al., draft-ietf-mpls-cr-ldp-03.txt, "Constraint-Based LSP Setup using LDP", September 1999 [MPLS_DIFF] Le Faucheur et al., draft-ietf-mpls-diff-ext- 04.txt, March 2000. [MPLS_RSVP] Davie et al., draft-ietf-mpls-rsvp-00.txt, `Use of Label Switching With RSVP', March 1998. [SCTP] Stewart et al, draft-ietf-sigtran-sctp-07.txt, `Simple Control Transmission Protocol', March 2000 [SS7 UAL] Morneau et al, draft-ietf-sigtran-m2ua-03.txt, `SS7 MTP2-User Adaptation Layer', March 2000 [ISDN UAL] Kalla et al, draft-ietf-sigtran-iua-02.txt, `ISDN Q.921-User Adaptation Layer', March 2000 [H323_RSVP] ITU-T, SG16/Q13, Geneva, Feb 2000, Delayed Contribution, `Enhancement for Synchronising RSVP with Slow Start'. Le Faucheur et. al 17 Bearer Control for VoIP & VoMPLS March 2000 10. Authors' Address Francois le Faucheur Cisco Systems, Inc. Les Lucioles - 291, rue Albert Caquot 06560 Valbonne France E-mail: flefauch@cisco.com Bruce Thompson Cisco Systems, Inc 375 East Tasman Drive San Jose, CA 95134 United States E-mail: brucet@cisco.com Angela Chiu AT&T Labs Room C4-3A22 200 Laurel Ave. Middletown, NJ 07748, USA Email: alchiu@att.com Le Faucheur et. al 18