2009年9月27日

IP - MLD (in IPv6) Multicast Listener Discovery (Study Note)

MLD (in IPv6) Multicast Listener Discovery

1). MLD Overview:

§ IPv6 multicast does not use the IGMP but rather the Multicast Listener Discovery (MLD) protocol.

§ MLD is derived from Version 2 of IPv4 IGMPv2.

§ MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links and to discover which multicast addresses are of interest to those neighboring nodes.

§ MLDv1 is similar to IGMPv2, and MLDv2 is similar to IGMPv3.

§ MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses, or from all sources except for specific source addresses, this being similar to SSM.

§ Recall that SSM is a form of multicast where a receiver must specify both the network layer address of the source and the multicast destination address to receive the multicast datagrams of interest.

§ MLD is based on RFC 2710 Version 1 Multicast Listener Discovery (MLD) for IPv6, and RFC 3810, Multicast Listener

Discovery Version 2 (MLDv2) for IPv6.

§ MLD [RFC 2710, RFC 3550, RFC 3810] specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (i.e., nodes wishing to receive multicast packets) on its directly attached links and to discover which multicast addresses are of interest to those neighboring nodes.

§ MLD enables IPv6 routers to discover the presence of multicast listeners. This information is then provided to the multicast routing protocol being used by the router to ensure that multicast packets are delivered to all links where there are interested receivers.

§ MLD is an asymmetric protocol, specifying different behaviors for multicast listeners and for routers.

§ For those multicast addresses to which a router itself is listening, the router performs both parts of the protocol, the “multicast router part” and the “multicast address listener part”, including responding to its own messages.

§ If a router has more than one interface to the same link, it needs to perform the router part of the MLD over only one of those interfaces.

§ Listeners, on the contrary, must perform the listener part of MLD on all interfaces from which an application or upper layer protocol has requested reception of multicast packets.

§ Note that a multicast router may itself be a listener of one or more multicast addresses; in this case it performs both the multicast router part and the multicast address listener part of the protocol to collect the multicast listener information needed by its multicast routing protocol on the one hand and to inform itself and other neighboring multicast routers of its listening state on the other hand.

2). MLD Message Overview:

§ MLD is a subprotocol of ICMPv6, namely, MLD message types are a subset of the set of ICMPv6 messages

§ One important difference is that MLD uses ICMPv6 message types (IP 58) rather than IGMP message types (IP 2).

§ MLD messages are identified in IPv6 packets by a preceding next header value of 58. All MLD messages are sent with a link-local IPv6 source address, an IPv6 hop limit of 1, and an IPv6 Router Alert option in a Hop-by-Hop Options header.

3). There are three types of MLDv1 messages:

1. Multicast Listener Query (type decimal 130), also known as “Query” (or Join)

§ There are two subtypes of Multicast Listener Query messages (differentiated by the contents of the Multicast Address field):

§ General Query, used to learn which multicast addresses have listeners on an attached link.

§ Multicast-Address-Specific Query, used to learn if a particular multicast address has any listeners on an attached link.

2. Multicast Listener Report (type decimal 131), also known as “Report”

3. Multicast Listener Done (type decimal 132), also known as “Done” (or Leave)

4). MLDv1 Message Format:

http://docs.google.com/View?id=ddh56dhg_221hp74wwgg

§ The Code field is initialized to zero by the sender; ignored by receivers.

§ The Checksum field is the standard ICMPv6 checksum, covering the entire MLD message plus a “pseudoheader” of IPv6 header fields.

§ The Maximum Response Delay field is meaningful only in Query messages and specifies the maximum allowed delay before sending a responding report, in units of milliseconds. In all other messages, it is set to zero by the sender and ignored by receivers.

§ The Reserved field is initialized to zero by the sender; ignored by receivers.

§ In a Query message, the Multicast Address field is set to zero when sending a general query and set to a specific IPv6 multicast address when sending a multicastaddress-specific query. In a Report or Done message, the Multicast Address field holds a specific IPv6 multicast address to which the message sender is listening or is ceasing to listen, respectively.

§ The length of a received MLD message is computed by taking the IPv6 payload length value and subtracting the length of any IPv6 extension headers present between the IPv6 header and theMLDmessage.

5). IGMP Message Type:

http://docs.google.com/View?id=ddh56dhg_223fkq32xxx

6). MLDv2 Message Overview:

§ There are three types of MLDv2 query messages: general queries, multicast address specific queries, and multicast address- and

source-specific queries.

§ Nodes respond to these queries by reporting their per-interface multicast address listening state through Current State Report messages sent to a specific multicast address of all MLDv2 routers on the link listen to. On the contrary, if the listening state of a node changes, the node immediately reports these changes through a State Change Report message.

§ Source filtering is based on RFC 4604. The term “Source Filtering GMP (SFGMP)” is used to refer jointly to the IGMPv3 and MLDv2 group management protocols.

7). Multicast Address Record Types

§ There are a number of different types of Multicast Address Records that may be included in a Report message:

§ Current State Record

  • IS_IN ( x ) =1 - Type MODE_IS_INCLUDE, source addresses x
  • IS_EX ( x ) =2 - Type MODE_IS_EXCLUDE, source addresses x

§ Filter Mode Change Record

  • TO_IN ( x ) =3 - Type CHANGE_TO_INCLUDE_MODE, source addresses x
  • TO_EX ( x ) =4 - Type CHANGE_TO_EXCLUDE_MODE, source addresses

§ Source List Change Record

  • ALLOW ( x ) =5 - Type ALLOW_NEW_SOURCES, source addresses x
  • BLOCK ( x ) =6 - Type BLOCK_OLD_SOURCES, source addresses x

8). MLDv2 Message Type:

§ There are two MLD message types of concern to the MLDv2 protocol described in this document:

§ Version 2 Multicast Listener Query (Type = decimal 130)

§ Version 2 Multicast Listener Report (Type = decimal 143).

§ To assure the interoperability with nodes that implement MLDv1, an implementation of MLDv2 must also support the following two message types:

§ Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710]

§ Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710]

9). MLDv2 Message Format:

Version 2 Multicast Listener Query

http://docs.google.com/View?id=ddh56dhg_225c6v5w6dw

Version 2 Multicast Listener Report

http://docs.google.com/View?id=ddh56dhg_227ftpm48c6


2009年9月24日

DVB-H Interface Study (CBMS1 ~ CBMS7)

Interface Further Study in DVB-H (CBMS1 ~ CBMS7)

1). Overall Protocol Stack:

http://docs.google.com/View?id=ddh56dhg_171fd5gqkf2

1.1). Service Access Points on the broadcast network

Solution

Service Access Points on the broadcast network Description

Service Access Points on the broadcast network Description

DVB-H

DVB Signalling

Access point mainly used by tuning and mobility management enablers to obtain relevant configuration information.

Streaming

AV Streaming

Access Point for all Audio/Video streams delivered over the Broadcast network

Download

File/Data Download

Access Point for all data delivered over the Broadcast network via FLUTE (one time or carousel based)

IP MC

IP Multicast

Access point to IP multicast for application specific usage of IP multicast.

UDP MC

UDP Multicast

Access point to UDP multicast for application specific usage of IP multicast datagram services.

1.2). Protocol Stack - Interface Used in DVB-H (CBMS)

http://docs.google.com/View?id=ddh56dhg_205g5bmqbg7

2). Reference Points / Interface and Fucntions:

2.1). Protocols over reference point CBMS-1

Ref Point

End Points

Usage

CBMS-1

From Broadcast network To Terminal

Broadcast network-specific singnalling, PSI/SI signalling in DVB-H.

http://docs.google.com/View?id=ddh56dhg_207gxbf8ghc

§ Reference point CBMS-1 is between broadcast network and terminal.

§ It is used to signal IP streams (TS) with PSI/SI information (or tables) over the broadcast bearer.

§ These protocols are subject of TS 102 470

2.2). Protocols over reference point CBMS-2

Ref Point

End Points

Usage

CBMS-2

From Service Application To Terminal

Content Flow, including:
• A/V streams.
• Auxiliary data.
• Files delivered by a carousel mechanism (clips, software, etc.).

http://docs.google.com/View?id=ddh56dhg_209fmqd9kfh

§ Reference point CBMS-2 is between service application and terminal.

§ It is used for content delivery over the broadcast network.

§ Both Stream Delivery (via RTP/UDP) and File Delivery (via FLUTE/ALC) are considered.

§ The contribution side for streams an encapsulation may be used as part of the head-end interface.

§ An RTP in TCP encapsulation method is defined in RFC 2326

§ These CDP protocols (Content Delivery Protocols) are subject of TS 102 472

2.3). Protocols over reference point CBMS-3

Ref Point

End Points

Usage

CBMS-3

From Service Management To Terminal

Electronic Service Guide (metadata, point-to-multipoint delivery).

http://docs.google.com/View?id=ddh56dhg_211f5jmd2g3

§ Reference point CBMS-3 is between service management and terminal.

§ The ESG is delivered (via FLUTE/ALC) on this reference point.

§ ESGC: Encoded ESG information is transported in ESG fragment containers.

§ L4/L5 protocol levels at the head-end side are subject of further study.

§ The ESG is subject of document “IP Datacast over DVB-H: Electronic Service Guide (ESG)”, the FLUTE/ALC/LCT delivery protocols are subject of TS 102 472

2.4). Protocols over reference point CBMS-4

Ref Point

End Points

Usage

CBMS-4

Between Service Management and Terminal

(only for the interactive network)

Electronic Service Guide (metadata, point-to-point delivery).

Access Control to service applications.
• This reference point exists only if the IPDC terminal includes an endpoint for the interactive network and if service management supports this reference point.

http://docs.google.com/View?id=ddh56dhg_213fsrfptgj

§ Reference point CBMS-4 is between service management (Logical ESG Aggregator) and terminal (Service and content description handler) over the interaction channel.

§ This reference point is optional. If available in the Terminal and configured for in the Service Management, it is used for ESG post delivery repair.

§ This reference point may be used e.g. to retrieve ESG information via the interaction channel. The current IP Datacast over DVB-H specification does not yet provide for this.

2.5). Protocols over reference point CBMS-5

Ref Point

End Points

Usage

CBMS-5

Between Service Application and Terminal

(only for the interactive network)

Point-to-point transport services (SMS/MMS, IP connectivity).
• This reference point exists only if the IPDC terminal includes an endpoint for the interactive network and if service application supports this reference point.
• Service applications may require this reference point.

http://docs.google.com/View?id=ddh56dhg_215fvh5s4hp

§ Reference point CBMS-5 is between service application and terminal via the interaction network.

§ This reference point is optional for terminals.

§ It is used for general interaction between terminal service applications.

§ In IP Datacast only for File Post Delivery Repair (via HTTP) it is defined up the application level.

§ File Post Delivery Repair is subject of TS 102 472

2.6). Protocols over reference point CBMS-6

Ref Point

End Points

Usage

CBMS-6

From Service Management To Broadcast network

Configuration of the DVB-H transport (number of services, allocated bandwidth, etc.).

http://docs.google.com/View?id=ddh56dhg_217cx9rctwv

§ Reference point CBMS-6 is between service management (resource provisioning and scheduling) and broadcast network (DVB-H service handler).

§ CBMS-6 comprises head-end interfaces. Therefore, mention of Muxconfig, SOAP, and SNMP are non-normative.

2.7). Protocols over reference point CBMS-7

Ref Point

End Points

Usage

CBMS-7

Between Service Application and Service Management

Service Application Declaration.
Service Application Description, including content description/metadata.

http://docs.google.com/View?id=ddh56dhg_2198bpxf7c5

Reference point CBMS-7 is between service application and service management.

§ CBMS-7 comprises head-end interfaces. Therefore, mention of SOAP is non-normative