One document matched: draft-schmidt-mmusic-sdp-local-identifier-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 04:31:36 |