MMUSIC M. Schmidt Internet-Draft H.J. Kolbe Intended status: Standards Track M. Stiemerling Expires: April 22, 2010 NEC Europe Ltd. October 19, 2009 SDP Local Identifier draft-schmidt-mmusic-sdp-local-identifier-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Schmidt, et al. Expires April 22, 2010 [Page 1] Internet-Draft Local Identifier October 2009 Abstract Dynamic Policy Controllers like resource and admission control systems need to be able to locate media receivers in each segment of the network to determine the path of the media flows prior to allowing or rejecting the session setup. Current definitions of SDP are not clear about conveying a local identifier (e.g. private IP address) of the client that is destined to receive media streams after successful SDP negotiation. In this draft we explain the need for carrying such information over SDP and discuss a set of possible solutions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 5 3. Unicast Use Case . . . . . . . . . . . . . . . . . . . . . . . 7 4. Multicast Use Case . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Schmidt, et al. Expires April 22, 2010 [Page 2] Internet-Draft Local Identifier October 2009 1. Introduction To perform resource and admission control inside home networks consisting of multiple home network devices (HNDs), the local admission controller which is usually incorporated inside the home gateway (HGW) must be made aware of which device in the home network requested multimedia session setup. Simply assuming that the source address of the signaling message will be the destination address for the media stream delivery is not sufficient since signaling and media rendering can take place on different HNDs. The HGW can either receive such information from snooping signaling using application layer gateways (ALGs) or it can learn it from a network-centric resource and admission control subsystem like ETSI TISPAN RACS [ETSI-RACS] or ITU-T RACF [ITU-T-RACF]. However, in case a HND uses encrypted signaling towards the operator network entities via e.g. IPSec as in the IP Multimedia Subsystem (IMS) case, an ALG-based approach relying on traffic snooping would fail: the HGW is unable to examine the signaling of the HND. In this case it becomes necessary that the HGW receives the HND identifier from the operator network side as depicted in the following figure: Home Network | Operator Network | +---------+ | +---------+ | HND1 | T | | SIP | | |. . . . . . . . . . .|. . . . .| Proxy | | | | | --------. | | | | | | +----.----+ | +-+--.----+ | | | | | | | | |B | | | | |a | | | | | | | | +----+----+ A | +---------+ | | HGW |---------. | RC | .---------------------| | | | | | | | | | | |b | | |----------------| | +----'----+ +----+----+ C +---------+ | HND2 | | | | | | | | | | | +---------+ | | | Schmidt, et al. Expires April 22, 2010 [Page 3] Internet-Draft Local Identifier October 2009 A HND (HND1 in above figure) uses SIP as signaling protocol with the SIP server or proxy over an encrypted signaling link via network connectivity denoted 'a' inside the Home Network and an Operator Network link 'A'. The signaling content is tunneled through the HGW (indicated by the virtual direct link 'T') and since it is encrypted, the HGW cannot examine/interpret the signaling - and is therefore not knowledgeable of the session setup request from HND1 and the associated session description. Based on the Session Description carried in SDP, the SIP infrastructure triggers the resource controller (RC) over link 'B' to reserve resources for the requested session. At current state of the art, policy control systems such as e.g. ETSI TISPAN RACS or ITU-T RACF reserve resources in the Access and Core Network, i.e. towards the Home Networks, but not inside those. To enable resource reservations also inside the home network either the HGW or the RC need to be aware of the home network resources and be able to perform admission control on session requests. For either case a link 'C' towards the Home Network is needed. Considering Home Network topology and resource status information to be a matter of privacy, the HGW becomes the admission control entity of choice for local resource control. Hence, the RC needs to pass the resource request to the HGW providing in this request also the HND identifier mentioned above. This enables the HGW to find the destination for the media stream (HND1 in above figure, the same HND that originated the signaling). Thus, there is a need to loop a local identifier from the source of the signaling (HND1) through the SIP/SDP infrastructure and the RC back to the HGW. Further to performing admission control for QoS purposes inside the Home Network, it also becomes possible to block IGMP/MLD join messages from HNDs that are not supposed to receive the stream. The HND identifier itself may be restricted to being only of local significance in case it is e.g., issued by the HGW. Examples are private IP addresses inside the Home Network or specifically issued identifiers by the HGW. Schmidt, et al. Expires April 22, 2010 [Page 4] Internet-Draft Local Identifier October 2009 2. Possible Solutions Concerning state of the art SDP as defined in RFC 4566 [SDP-RFC], the related information could be carried in 1. The c-line which indicates where the HND would like to receive media. However, in case of multicast services such as Linear IPTV (also referred to as Broadcast IPTV in ETSI TISPAN), the c-line carries a multicast address and is not suitable to identify the requesting HND. Moreover, even in the case of unicast sessions this line might not be reliable since it can be impacted by NAT traversal steps re-writing this line. 2. The o-line which indicates the origin of the session. This could carry a CPN-local identifier in principle, however this would violate the SDP RFC 4566 [SDP-RFC] which forbids to carry a local identifier in the o-line to a domain where it has no significance. In addition, Operator Network entities are unlikely to process this parameter for resource reservation purposes. 3. The s-line which carries the session name. In principle it could be used to carry the HND identifier requesting the session, however Operator Network entities are unlikely to process this parameter for resource reservation purposes. 4. The i-line which can carry any kind of information on the session or media. While usage of this parameter is possible in principle, current Operator Network entities such as the P-CSCF of IMS are not likely to process the i-line for the purpose of requesting resources. 5. The a-line on session or on media level. This line is examined by the Operator side entities for resource reservation purposes at present. A new parameter like 'HND-id' would need to be registered. 6. A new line in SDP. This would require extending the SDP standard or defining a new standard for this line and its semantics. It appears beneficial to allow the parameter to be carried on either session or media level, as the carriage on session level can indicate a scenario where all media lines requested are associated to the same HND which might or might not be identical with the signaling HND setting up the session. Defining it on media line level would allow to associate individual media lines to individual different HNDs, e.g. in case of IPTV services, there could be different media rendering devices indicated for video and audio (e.g. TV screen and Schmidt, et al. Expires April 22, 2010 [Page 5] Internet-Draft Local Identifier October 2009 HIFI stereo). This is another indicator against using the o-line or the s-line which are only carried on session level. Taking this into account and looking at these six options, options 5 and 6 appear to be the most suitable solutions. Taking into account e.g. current ETSI TISPAN NGN standards where the content of the a-line is to be sent to the RACS over the so-called Gq' interface using the codec-data AVP (cf. 3GPP TS 29.214, section 5.3.7), it appears that option 5 is preferable. A question remains on the information to be carried in the HND identifier parameter. At present, HND IP-address seems suitable, but in principle, also any other parameter could be used as long as the HGW is able to resolve it. Thus, it is proposed to allow an IP address or a generic octet string in this parameter. The following examples base on IMS based IP TV as defined in [ETSI-IPTV] and show the use of an additional a-line for transporting the local identifier named "LID" (here: IP address, optionally with port). Note that they include the HND IP address also in the o-line which is currently not RFC-compliant. Schmidt, et al. Expires April 22, 2010 [Page 6] Internet-Draft Local Identifier October 2009 3. Unicast Use Case In the following example SDP based on ETSI TISPAN IMS based IPTV [ETSI-IPTV] is sent from a HND during session initiation (carried in a SIP INVITE request towards the Operator Network) in case of content on demand (CoD), i.e. requesting unicast traffic. Due to the considerations described above, the local address of the media- receiving HND carried in the SDP cannot be used for resource admission control inside the Home Network. v=0 o=jdoe 2890844526 2890842807 IN IP4 192.168.0.1 s=Unicast COD Movie t=2873397496 2873404696 m=application 9 tcp iptv_rtsp c=IN IP4 192.168.0.1 a=setup:active a=connection:new m=video 51372 RTP/AVP 33 a=recvonly b=AS:15000 c=IN IP4 192.168.0.1 In the subsequent example SDP, the HND identifier in form of a local IP address is carried on the session level through the parameter a=LID:192.168.0.1. Through this, assuming a network setup as described above and using encrypted signaling between HND and the SIP Proxy, the HGW can (through receiving it from the RC) identify the device destined for the media session which includes an RTSP link as well as a high bandwidth video stream. The HGW then can act as a resource controlling entity, e.g. by prioritizing traffic or by replying negatively to the RC in case e.g. in-home links are not capable of handling the requested media. v=0 o=jdoe 2890844526 2890842807 IN IP4 192.168.0.1 s=Unicast COD Movie t=2873397496 2873404696 a=LID:192.168.0.1 m=application 9 tcp iptv_rtsp c=IN IP4 192.168.0.1 a=setup:active a=connection:new m=video 51372 RTP/AVP 33 a=recvonly b=AS:15000 c=IN IP4 192.168.0.1 Schmidt, et al. Expires April 22, 2010 [Page 7] Internet-Draft Local Identifier October 2009 4. Multicast Use Case The subsequent SDP example shows the SDP data send by the HND based on [ETSI-IPTV] for "Broadcast IPTV" using IP multicast for media distribution: v=0 o=jdoe 2890844526 2890842807 IN IP4 224.2.17.12/127 s=Multicast session t=2873397496 2873404696 m=video 51372 RTP/AVP 33 c=IN IP4 224.2.17.12/127 a=bc_service:BCServiceIdtoJoin a=recvonly In this example SDP it is apparent that the HGW cannot identify the requesting HND when contacted by the RC upon session initiation because the SDP carries the IP address of the multicast group it intends to join (corresponding to the bc_service parameter, both received e.g. through an Electronic Program Guide) which translates into one Broadcast IPTV channel. The subsequent example SDP additionally carries the HND identifier ('HND1') as a string on media line level to enable the HGW to identify the destined HND inside the Home Network. Note that the HND identifier could also be carried on session level as described in the unicast SDP example above. Note also that instead of carrying a string ('HND1'), also a local ip address could be used - as long as it is suitable for identifying the destined HND unambiguously inside the Home Network. v=0 o=jdoe 2890844526 2890842807 IN IP4 224.2.17.12/127 s=Multicast session t=2873397496 2873404696 m=video 51372 RTP/AVP 33 c=IN IP4 224.2.17.12/127 a=bc_service:BCServiceIdtoJoin a=recvonly a=LID:HND1 Above example shows that in a private network even two different HNDs requesting the same multicast traffic become distinguishable by the HGW through the use of a local HND identifier parameter. Note that through this, as mentioned above, also a rejection or blocking of IGMP/MLD join messages of HNDs that are not supposed to receive the multicast media stream becomes possible inside the Home Network. Schmidt, et al. Expires April 22, 2010 [Page 8] Internet-Draft Local Identifier October 2009 5. Security Considerations This initial version of this memo does not yet have any security considerations, but they will be added with the next revision. Schmidt, et al. Expires April 22, 2010 [Page 9] Internet-Draft Local Identifier October 2009 6. Conclusion We have outlined the need to convey a local identifier of Home Network Devices through a domain where it has no significance back to the Home Network for resource and admission control purposes. In these considerations the focus lay on carrying this identifier in SDP. To define the means to carry the identifier discussions and reflections are sought on the different considerations presented above. This memo is work in progress and is requesting feedback from the MMUSIC working group. Schmidt, et al. Expires April 22, 2010 [Page 10] Internet-Draft Local Identifier October 2009 7. References 7.1. Normative References [SDP-RFC] IETF, "SDP: Session Description Protocol", RFC 4566, July 2006. 7.2. Informative References [ETSI-IPTV] ETSI TISPAN, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification", TS 183 063 V2.1.0, June 2008. [ETSI-RACS] ETSI TISPAN, "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS): Functional Architecture", ES 282 003 V2.0.0, May 2008. [ITU-T-RACF] ITU-T, "GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS Next Generation Networks - Quality of Service and performance Resource and admission control functions in Next generation networks", Recommendation Y.2111, November 2008. Schmidt, et al. Expires April 22, 2010 [Page 11] Internet-Draft Local Identifier October 2009 Authors' Addresses Mischa Schmidt NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 162 Fax: +49 6221 4342 155 Email: schmidt@nw.neclab.eu URI: http://www.nw.neclab.eu/ Hans-Joerg Kolbe NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 216 Fax: +49 6221 4342 155 Email: kolbe@nw.neclab.eu URI: http://www.nw.neclab.eu/ Martin Stiemerling NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 113 Fax: +49 6221 4342 155 Email: stiemerling@nw.neclab.eu URI: http://www.nw.neclab.eu/ Schmidt, et al. Expires April 22, 2010 [Page 12]