One document matched: draft-schmidt-mmusic-sdp-local-identifier-01.txt
Differences from draft-schmidt-mmusic-sdp-local-identifier-00.txt
MMUSIC M. Schmidt
Internet-Draft H. Kolbe
Intended status: Standards Track M. Stiemerling
Expires: December 3, 2011 NEC Europe Ltd.
June 1, 2011
SDP Local Identifier
draft-schmidt-mmusic-sdp-local-identifier-01
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. This is fine as long as
this is handled within an operator's network but limited when
extending this to home network. Current definitions of SDP are not
clear about conveying a local identifier (e.g., a private IP address)
of the client that is destined to receive media streams after
successful SDP negotiation. In this draft we outline the need for
carrying such information over SDP and discuss a set of possible
solutions in a scenario with a home network and a operator network
domain.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 3, 2011.
Copyright Notice
Copyright (c) 2011 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
Schmidt, et al. Expires December 3, 2011 [Page 1]
Internet-Draft Local Identifier June 2011
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 December 3, 2011 [Page 2]
Internet-Draft Local Identifier June 2011
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 the setup of the multimedia session. 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, as for instance,the
ETSI TISPAN RACS [ETSI-RACS] or the 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, or tunneled cases as with 3GPP access or femto cells, 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 |
| | | | +-------+
| | | | | |
+----.----+ | +----+----+ |
| | | |
a| | | |B
| | | |
| +---------+ A | +-----+---+
| | HGW |---------+ | RC |
.---------------------| | | |
| | | | |
|b | |----------------| |
+----'----+ +---------+ C +---------+
| HND2 | |
| | |
| | |
| | |
+---------+ |
|
|
Figure 1: Home Network Scenario
Schmidt, et al. Expires December 3, 2011 [Page 3]
Internet-Draft Local Identifier June 2011
A HND (HND1 in Figure 1) uses SIP as signaling protocol with the SIP
server or proxy over an encrypted signaling interface via network
connectivity denoted 'a' inside the Home Network and an Operator
Network interface 'A'. The signaling content is tunneled through the
HGW (indicated by the direct interface 'T') and as 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 interface 'B' to reserve resources for the
requested session. Currently, 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 interface '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.
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 December 3, 2011 [Page 4]
Internet-Draft Local Identifier June 2011
2. Possible Solutions
With SDP [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. In
principle, this could carry a local identifier meaningful to the
home network, 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
HIFI stereo). This is another indicator against using the o-line or
Schmidt, et al. Expires December 3, 2011 [Page 5]
Internet-Draft Local Identifier June 2011
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 December 3, 2011 [Page 6]
Internet-Draft Local Identifier June 2011
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
interface 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 interfaces 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 December 3, 2011 [Page 7]
Internet-Draft Local Identifier June 2011
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 December 3, 2011 [Page 8]
Internet-Draft Local Identifier June 2011
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 December 3, 2011 [Page 9]
Internet-Draft Local Identifier June 2011
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 December 3, 2011 [Page 10]
Internet-Draft Local Identifier June 2011
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 December 3, 2011 [Page 11]
Internet-Draft Local Identifier June 2011
Authors' Addresses
Mischa Schmidt
NEC Laboratories Europe
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 162
Fax: +49 6221 4342 155
Email: mischa.schmidt@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@neclab.eu
URI: http://www.nw.neclab.eu/
Martin Stiemerling
NEC Laboratories Europe
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 113
Email: martin.stiemerling@neclab.eu
URI: http://ietf.stiemerling.org
Schmidt, et al. Expires December 3, 2011 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 04:29:41 |