Programmable Group Communication Services over IP Multicast
`Dr. Michael Smirnov, Henning Sanneck, Dorota Witaszek, GMD FOKUS GloNe, Germany
`
`Abstract
`
`Advances in high speed routing and switching devices in recent years make it possible to facilitate both new network
`services such as group communication, and to increase the level of router programmability. Programmability is
`considered as a feature not only allowing to better meet applications requirements (user viewpoint) but also to
`optimise network resources (provider viewpoint). We show how multicast - one of the mechanisms which allows
`providers to save network resources - could be used to design a new service (group communication) and to become
`programmable. Our approach is to concentrate on a protocol co-design, when several protocols which have to
`interoperate in order to achieve a common goal are sharing the same resources (mainly - state information) dispersed
`over the network. By this we achieve better scaling features for higher level services supported by the protocols
`under co-design. The main advantage of our proposal is that new services introduced could be deployed
`incrementally.
`
`1. Introduction
`
`1.1 Deployment considerations
`
`There have been many discussions in recent years about
`practical applicability of IP multicast service model ( 1 J.
`The
`lack of providers'
`control over multicast
`membership and content has been identified as the main
`drawback of IP multicast (2]. In order to make multicast
`more deployable many argued that the service model
`itself should be changed. An excellent background
`material- motivation and requirements - for this view
`could be found in [3].
`In this paper we present another approach. We argue
`that there is no need to modify IP multicast service
`model while it should be considered as a building block
`for higher
`level services
`(we call
`these Group
`Communication Services) which should feature needed
`controls. Further, to facilitate controls over membership
`and content we propose to make service components
`programmable to an extent which is currently feasible.
`Rather than following active networks paradigm in
`tailoring network elements to meet user and provider
`requirements we follow slightly modified client server
`approach to achieve the same goal.
`We introduce a new service model dubbed mediated
`Group Communication. In this model we have a new
`logical
`entity
`above
`IP multicast
`Group
`Communication Mediator (GCM). Main semantics of IP
`multicast are retained (it's our building block), i.e. we
`retain group membership as being under the supervision
`of receivers, we do not consider a sender to a group to
`be necessarily a member of a group. We build a GCM to
`he back compatible with native IP multicast [l).
`
`Consider a set of hosts Hand a set of groups G in which
`these hosts participate. We define then a meta group GH
`as a union of all the groups {g 1, g2, ••• ) which belong to
`G and one special group g0 which consists of one or
`more GCMs. We show later that all other members of G
`are sending their control messages to So, and so in turn
`controls group R -- a group of all multicast border
`routers in GCM domain.
`
`1.2 Advances in high speed routers
`
`routers perform processing of
`Current generation
`packets and execute routing and signalling protocols.
`Routers perform
`fast packet
`forwarding on
`the
`"forwarding path" which is in contrast to the "control
`plane" of a router where control protocols (routing
`management and signalling) are run under an operating
`systems. In this paper we follow an approach of the
`Generic Router Assist - ORA [4] in an attempt to
`increase router programmability while keeping the
`essential split between control and forwarding paths.
`A router forwarding path usually consists of specially
`designed hardware and software tailored for the purpose
`of forwarding packets. Newer routers also have abilities
`to perform other actions such as marking or policing for
`services such as QoS. In general, the forwarding path of
`routers is very limited in the amount of state and
`complexity of processing that can be performed.
`Router control planes run embedded or general
`operating systems. On top of these operating systems
`are implementations of IP control protocols such as
`routing, signaling, and network management. Most
`GRA operations as pointed in [4] will be performed in
`
`281
`
`CISCO EXHIBIT 1014
`Smirnov
`
`

`

`the control plane where state and processing power are
`more readily available.
`High speed routers appearing in the market typically
`have
`in
`their
`forwarding path multiple
`routing
`processors (forwarding engines performing IP layer
`silicon forwarding, and routing engines performing
`silicon route retrieval, which is a combination of a
`routing look-up and a multi-purpose filtering to support
`QoS, IP multicast, etc.) interconnected by a high
`performance switch. The control plane -
`routing
`manager - is also connected to the internal switch.
`
`The rest of the paper is structured as follows. In the next
`section we introduce three sample group communication
`services based on GCM groups, and explain why and
`how these services could be deployed incrementally.
`Then, we concentrate on the architecture - entities,
`protocols,
`interfaces, message
`exchange
`-
`to
`demonstrate that it fits all proposed services, i.e. is
`generic enough. After that we explain in more details
`new protocols under co-design. We conclude with the
`discussion and future w0rk.
`
`1.3 Light weight router programmability
`
`•
`
`•
`
`To be acceptable router programmability services are
`only to be invoked for certain packets; data packets
`should not be treated any differently and therefor
`should not cause any additional processing in routers.
`As an example of further properties and requirements let
`us consider those for GRA [4].
`Properties of ORA based services:
`•
`Fixed - they are statically part of router software or
`hardware. They are not dynamically
`loadable
`modules.
`Simple - only to include those services that are felt
`reasonable to be implemented in routers. These are
`services which can be performed with minimum
`CPU and memory overhead.
`Short Term - to provide services for which state and
`processing overhead is short lived, make use of
`soft-state design principles.
`Complete requirements list of GRA based services
`could be found in (4), however here we would like to
`stress the following one:
`This services should not directly participate in any
`transport protocol.
`Based on the above approach we assume for the rest of
`the paper that the following features are available at
`routers:
`routing engines are capable of
`Forwarding path:
`performing IP packets filtering, support IP multicast and
`in our case we assume a set of GCM filters
`QoS -
`(GCMF) which occur as a part of route retrieval;
`The above value added features are managed by the
`routing manager through filtering, QoS and multicast
`management interfaces of routing engines;
`Control plane: routing manager can run application
`level software which may access engines' filtering, QoS
`and multicast management interfaces.
`The GCMF here is a generic term for any pre- and/or
`post-processing of a routing table look-up result.
`The rest of the paper explains how these interfaces
`could be used by GCM entity to programme IP
`multicast on behalf of GCM group members.
`
`2.
`
`Value added services over IP
`Multicast
`
`2.1 GCM Groups
`
`All services introduced below, and potentially others are
`making use of the so called mediated groups. Our
`proposal is to use IP multicast as a primitive network
`building block for all these services.
`GCM groups are groups made of hosts residing in a
`single GCM domain. GCM domain is defined as a [set
`of] network domain[s] served by a single instance of
`GCM. GCM's address is well known to every host in
`that domain. These groups are not advertised outside the
`domain as GCM groups, however may be advertised as
`native IP multicast groups. Fig. 1 shows the relationship
`between native IP multicast and mediated groups. A
`host is said to be a member of a GCM group if it has
`successfully registered with the GCM.
`
`All hosrs Internet wide
`subs<ribed to IPMCA
`
`Fig. 1 Native IP multicast groups and mediated
`groups
`
`GCM groups like native IP multicast groups are
`identified by GCM Address (GCMA) which is IP Class
`D address, or IP MultiCast Address (IPMCA). If a
`registration information of any host to a particular
`GCMA did not specify any IPMCA this would mean
`
`282
`
`CISCO EXHIBIT 1014
`Smirnov
`
`

`

`that GCM group is a private one. This does not mean
`that no other receivers Internet wide are possible to the
`same sources as for a private GCM group.
`Private GCMA addresses are borrowed from the same
`address space as IPMCA, therefor it is recommended
`that each GCM selects for GCMA that sub-range of
`class D which will assure minimum probability of
`clashes within the GCM domain between private and
`public addresses. For example, a set of private addresses
`managed by a GCM could be that which:
`1. Does not belong to the same MASC domain to
`which GCM domain belongs;
`Is borrowed from the IP multicast prefix range
`managed by the far most MASC domain.
`The latter could be achieved for example by borrowing
`from the MASC range allocated to a domain several
`time zones away in MASC hierarchy from the current
`GCM domain. However, clearly realising that such
`measures are not sufficient to avoid address clashes
`entirely, we have developed a special private address
`management protocol , which is completely safe in the
`sense of possible clashes between GCMA and IPMCA..
`Next 3 sections outline GCM operation for 3 proposed
`sample services, which are
`then concluded with
`deployment considerations.
`
`2.
`
`2.2
`
`Unicast to Multicast
`
`This service will be introduced by an example. Consider
`a television on demand server which sends real-time
`video data to every subscriber over a set of unicast (for
`revenue protection reasons) paths. Consider also several
`subscribes to this service in the same GCM domain.
`Given that a [sub]group of these subscribes might have
`the same QoS preferences, GCM could be used to map a
`single unicast transmission to a GCM group inside its
`domain via IP multicast. In this case there still exists an
`issue of a content provider's revenue protection inside
`the GCM domain, however similar issues exist for any
`service which is consumed from behind a NAT [5] for
`example.
`it keeps explicit
`in this scenario:
`GCM is useful
`registration of any individual user of a service (content
`based charge is safe). At the same time mapping of a
`unicast to GCM private group saves internal resources
`of a network provider- this is exactly what multicast
`was designed for.
`In the routers' forwarding path IP datagram accepted by
`a forwarding engine from a network interface is kept in
`a packet buffer during
`the silicon
`table
`lookup
`performed by a routing engine. GCMF functionality
`inside a routing engine in this case is rather simple:
`prior to a routing table look-up IP destination address is
`checked against
`those GCM controlled unicast
`
`addresses which are known to have GCM subscribers.
`On positive result, IP unicast address is exchanged to
`GCMA specified for this source. After that a routing
`table look-up is done which returns a set of router's
`outgoing interfaces (OIF) for this GCM group. To
`further speed up the process GCM based routing table
`could be kept separately from the general purpose
`routing database.
`There is a policy issue: Whether it will be allowed in a
`GCM domain to have the GCM '·unicast to multicast"
`service in parallel with native unicast from the same
`source? (Recall, the incentive was to save domain's
`resources). If the answer is positive, then the GCMF
`functionality sketched above should include replication
`of a unicast datagram (which is a routine task anyway)
`and forward it as appropriate. It seems rational to ask a
`host willing to be the destination for the same source for
`both - unicast and GCM group -to mention this
`explicitly in its GCM registration. This excludes double
`forwarding of the same data which - one of the copies -
`is then dropped by the host. The default policy then will
`be to forward unicast only to those destinations which
`are not at the same time in a GCM group.
`
`2.3
`
`Native IP Multicast to GCM
`
`Another GCM based service is mapping of native IP
`multicast to GCM groups inside GCM domain. A
`motivation for such a mapping is to have controllable
`group membership, and to assure members' preferences
`such as QoS requirements, etc.
`from one address
`Mapping of multicast packets
`(IPMCA) to another multicast address (GCMA) is even
`easier for the routing engine - a datagram is already on
`the "multicast track":
`Routing and forwarding engines are already triggered to
`replicate the datagram and to forward it to a set of OIFs;
`•
`There
`is
`no
`influence
`on
`semantics
`of
`communication at application
`level
`if proper
`bindings are done (i.e. in hosts and router);
`• GCMF functionality is enabled only on those OIFs
`towards GCM domain which are stub networks in
`the native multicast distribution tree; inter-domain
`native multicast routing is not involved on these
`OIFs and it does not matter which addresses are
`used;
`• Many link layer technologies can be deployed in
`subnets (Ethernet, ATM, etc.) which will anyway
`require address resolution to hardware addresses;
`this is very natural to be done by GCM enhanced
`with ARP functions (this is exactly what was done
`in our previous work on IP multicast over ATM
`[6]).
`
`283
`
`CISCO EXHIBIT 1014
`Smirnov
`
`

`

`On contrary to the previous case there is however a
`strong need to support inside GCM domain both native
`IP multicast and GCM groups. This support will
`facilitate incremental deployment of GCM services in
`both hosts and routers. Another reason is to assure back
`compatibility with native IP multicast from inside GCM
`domain at application level.
`
`2.4 QoS assured Multicast
`
`In the both examples above we required GCM support
`of user signalled preferences in GCM. If one wants to
`meet QoS requirements and at the same time to make
`advantages of multicast forwarding, one should limit the
`amount of quality classes. Reasonably limited number
`of QoS levels will allow to cluster several receivers with
`similar QoS preferences in a single QoS sub-group and
`to establish a separate multicast path (tree) to this sub(cid:173)
`group. We have followed this approach in our earlier
`work on lP multicast over ATM detailed in [6, 7].
`this service - Multicast
`implementation of
`Our
`Integration Server (MIS) - uses IntServ approach for
`QoS signalling with RSVP [6], however the Quality of
`Service Support Interface (QSSI) is specified in a
`generic way and fits well into the GCM architecture.
`Providing end to end QoS however requires more
`processing of a router control plane (e.g. forwarding of
`RSVP PATH message to GCM, etc.).
`GCMF functionality to be provided in the routing
`engine (forwarding path) is comprised of one additional
`filter, and one additional address mapping per QoS
`class. Coexistence of native and mediated multicasts is
`definitely a challenge and we explain our solution in
`section 4.2.
`
`2.5
`
`Incremental deployment considerations
`
`GCM services allow coexistence of native IP multicast
`and GCM
`groups,
`thus
`allowing
`incremental
`deployment on all levels: application, host protocol
`stack, router.
`Another advantage is GCM's help in solving router
`migration problem exposed in [3]: usual practice is after
`an upgrade of a backbone to move legacy core routers to
`customers premises, thus enlarging routers service time.
`The problem is that legacy core routers very often do
`not support IP multicast. We see the business case in
`using legacy routers upgraded by GCM service in
`customers' networks:
`•
`Packet replication in routers is usually not an issue,
`but support for multicast routing is hard - we
`
`•
`
`•
`
`consider it much easier to implement GCMF locally
`controlled at each router than to implement native
`IP multicast support;
`If GCM service is considered useful by a provider
`then it will still remain needed for the next stage
`router migration - GCM is needed at edge routers
`only, core backbone routers will not need this and
`after migration will anyway require such an
`upgrade;
`If provider
`a proprietary group
`using
`is
`communication service (e.g. UUcast - a mixture of
`unicast to proxy and multicast from proxy to
`receivers [3]) which is not compatible with other
`native IP multicast implementations, then using
`GCM between proprietary implementations and
`native IP multicast solves the problem via address
`mapping for example.
`Last but not least providers motivation for GCM model:
`likewise the receivers are not motivated to use multicast
`(they do not care how the data are transported) domains
`are not motivated to complicate their life in order to
`ease the life of neighbour domains. Consider a domain
`with a singe source and only few receivers whith the
`rest of the group outside the source domain. The main
`motivation to use multicast belongs to the other domains
`in this case. If multicast is made programmable - self(cid:173)
`constructive then this motivation can trigger unicast to
`multicast mapping at the border between domains.
`
`3
`
`Architecture
`
`3.1
`
`Client-server model generalisation
`
`to peer
`for peer
`server paradigm
`The client
`Internet. Recently,
`communication dominates
`the
`however some modifications of this model could be
`seen when the role of one of the peers could be
`dynamically changed from client to server and back
`based on semantics of the message exchange, e.g. SIP
`[8]. The word agent is widespread to dub such a
`modification. However, our approach is to concentrate
`on a protocol co-design, when several protocols which
`have to interoperate in order to achieve a common goal
`are sharing
`the same
`resources
`(mainly -
`state
`information) dispersed over the network. By this we
`hope to achieve better scaling features for higher level
`services supported by the protocols under co-design.
`The result of a co-design process is ideally marginal
`effort in coding, however significant improvements in
`performance.
`
`284
`
`CISCO EXHIBIT 1014
`Smirnov
`
`

`

`3.2 GCM Entities
`
`3.4
`
`Interfaces
`
`Group oornmunicatbn
`mecfoalOr(gcm)
`
`$
`
`NanORA
`
`IP--
`l
`
`Fig. 2 Entities of GCM Services in a romain
`
`Engineering view on native IP multicast typically
`considers the following entities:
`•
`hosts sending and receiving multicast datagrams;
`a set of hosts announced
`• multicast group -
`themselves as receivers - identified IPMCA and
`sometimes by a sender address (sender is not
`considered to be group member)- so called source
`specific group;
`• multicast routers forwarding IP multicast datagrams
`to group members comprising dynamically created
`and modified multicast distribution tree.
`We are not considering here entities specific for
`particular multicast
`routing protocols,
`such
`as
`rendezvous points in PIM [9], core routers in CBT [10]
`and simple multicast [ll], etc.
`We have added one more entity - GCM (Fig. 2), and
`consequently - GCM groups (Fig. 1). Obviously, the
`complexity of the mediated group communication
`service is higher than that of native IP multicast and
`requires additional protocols. Our design goal is to use
`as much as possible state information developed by
`existing protocols and to keep these additional protocols
`simple.
`
`3.3
`
`List of protocols under co-design
`
`The following protocols are considered to be under the
`co-design process:
`•
`Internet Group Management Protocol (IGMP) [12];
`• Group Communication Mediation
`Protocol
`(GCMP);
`Private Group Address Management Protocol
`(PGAMP);
`• GCM Filter Management Protocol (GFMP).
`
`•
`
`Mediated Group Management (MGM) module provides
`following interfaces:
`•
`an interface to the client (MGM-GCC);
`•
`an interface to the Group Address Management
`(MGM-GAM);
`an interface to Group Subscription (MGM-GS);
`•
`an interface to an GRA router(s) (MGM-GCF).
`•
`Multicast Border
`router
`(GRA
`router) provides
`following interfaces.
`•
`an interface to GCM;
`•
`an interface to multicast routing data (Fwd);
`an interface to other facilities of a router control
`•
`plane (policy, admission control, etc.).
`Fig. 3 shows these and other interfaces, like inter(cid:173)
`domain MGM-MGM interface, and interfaces of the
`(GAM):
`towards
`Group Address Management
`Subscription unit (to e.g. perform a subscription
`delegated by a host); towards standard IETF Multicast
`Address Allocation server (Malloc).
`
`GCMclient
`
`' :
`Fwd !
`'
`
`GRA Rtr
`
`fillers
`
`Fig. 3 GCM Interfaces
`
`As the core of the mediated multicast is the Mediator,
`we concentrate in the next section on the definition of
`its interfaces. Interfaces are defined through sets of
`messages exchanged between subsequent protocol
`entities over this interface.
`
`3.5 Messages
`
`Table 1 explains messages per GCM interface together
`with their parameters and a type, which indicates the
`direction of message exchange (in or out) with respect
`to the first protocol entity in the interface definition. For
`example, Join-Req has type in for MGM-GCC interface
`because it is an incoming message with respect to MGC.
`
`285
`
`CISCO EXHIBIT 1014
`Smirnov
`
`

`

`•
`
`from a
`
`• mediated- a flag for mediation mode,
`SFI in the case of unicast-to-multicast scenario it is
`•
`the source IP address and the source port,
`• Rec - an IP address of a receiver;
`• Dport - a destination port address.
`• PDA- proxy destination address
`• GCA - private multicast address used inside the
`domain for the group
`P-Options -
`additional options sent
`subscriber (GS)
`• Key - a key to recognise the mediated traffic at the
`GRA router, the key has to have more complex
`structure describing the sort of the key and its
`value. The key should be here the proxy address
`with an optional DPort (an IP address and a port
`number, or a part of it);
`• OPT-REQ - optional requirements common for all
`clients which belong to this entry (not studied here),
`• mge - a flag which should tell the router that the
`entry is a new one.
`The subscription uses an identifier which we generally
`call the Subscription Flow Identifier (SFI). In the
`multicast to multicast scenario the SFI could be an IP
`multicast address which is used by a source (IPMCA)
`and destination port with optional fields such as source
`identification (source IP address, source port). In the
`case of unicast to multicast scenario the SFI could be a
`source IP address and a source port. In the following
`section we explain the behaviour based on the unicast to
`multicast scenario.
`
`4
`
`Protocols
`
`4.1 Membership and QoS management
`
`Message Sequence Chart in Fig. 4 gives an example of
`
`GCC
`Join-Rec
`~
`(mediated, SFI, Rec) • Get-Address ()
`
`MGM
`
`GAM
`
`GS GCF
`
`:,
`New-Address (GCA)
`
`- S
`
`tart-Session (SFI)
`
`;
`Start-Session-Ack (SFI Dpo,1, POA)
`
`-M
`
`ap (Key, SFI, GCA, Oport, nge)
`
`.
`Map-Ack I Key, SFI, GC 'Opo,t)
`
`Join-Rec-Ack
`(mediated, SFI, GCA
`Dport, Rec)
`
`Fig. 4 MSC for successful mediated Join
`
`Table 1. GCM Messages and Interfaces
`
`IF
`
`Message
`Name
`Join-Req
`
`Message
`Parameters
`mediated, SFI, Rec,
`OPT-REO
`SFI,
`Join-Req-Ack mediated,
`GCA, Dport, Rec,
`OPT-REO
`SFI,
`mediated,
`GCA, Dport, Rec,
`OPT-REQ,
`error code
`SFI,
`mediated,
`GCA, Dport, Rec,
`OPT-REO
`SFI,
`Leave-Req- Mediated,
`Ack
`GCA, Dport, Rec,
`OPT-REO
`Key, SFI, GCA,
`Dport, mge
`Key, SFI, GCA,
`Dport
`Key, SFI, GCA,
`Dport, reason
`Key, SFI, GCA,
`Dport
`Unmap-Ack Key, SFI, GCA,
`Dport
`
`Join-Req-
`MGM- Nack
`GCC
`
`Leave-Req
`
`Map
`
`Map-Ack
`
`MGM-
`GCF Map-Nack
`
`Unmap
`
`GCA, status
`
`MGM-
`GAM
`
`Get-Address
`New-Address GCA
`Address-
`GCA, status
`lnUse
`Address-
`In Use-Ack
`Free-Address GCA
`Free-
`GCA
`Address-Ack
`Start-Session SFI
`Start-Session- SFI, Dport, PDA,
`Ack
`P-Options
`SFI, Dport, PDA
`Session-
`Refresh
`MGM- Session-Ack SFI, Dport, PDA,
`P-Ootions
`GS
`Session-Nack SFI,
`reason, opt.
`Dport, opt. PDA
`Stop-Session SFI, Doort, PDA
`The following abbreviations are used in Table 1:
`
`Type
`
`In
`
`out
`
`out
`
`in
`
`out
`
`out
`
`in
`
`in
`
`out
`
`in
`
`out
`in
`out
`
`in
`
`out
`in
`
`out
`in
`
`out
`
`in
`
`in
`
`out
`
`286
`
`CISCO EXHIBIT 1014
`Smirnov
`
`

`

`request processing, while Fig. 5
`successful Join
`provides MSC for successful Leave request processing.
`
`MGM
`
`GCC
`Leave-Rec
`-"
`(mediated, SF!. GCA -
`Dport. Rec)
`
`GAM
`
`GS GCF
`
`Stop-Session (SFI. Dport, f µA)
`
`Unmap \Key. SFI. GCA. Dp n)
`
`.
`-
`
`Session•Nack {SFI, reason, Dport. PDA)
`1~
`
`Unmap-Ack (I ey, SF!. GC~ Dpon)
`
`,~
`Free-Address (GCA)
`
`~
`
`Free-Address-Ack (GCA)
`
`D addresses (IPMCA, GCA). A GCA denotes the so
`called private IP Class D address which uniquely
`identifies GCM group inside the GCM domain, an
`IPMCA is globally unique, public Class D address.
`Global addresses are either statically allocated, or
`managed by
`the Multicast Address Allocation
`Architecture with a multicast address set claim (MASC)
`protocol [ 13] at the very top of its hierarchy as proposed
`by the IETF [ 14]. On contrary to this, GCMA addresses
`are managed by a GCM (hence, private). ). In case of a
`private group IPMCA address field is initially zeroed in
`GCM's cache.
`
`Leave-Rec-Ack 1 •
`' • (mediated, SFI, GCA
`Dport, Rec) I
`
`4.2
`
`Private multicast addresses
`management
`
`I
`
`Fig. 5 MSC for successful mediated Leave
`
`These MSC in combination with Table l fully define
`interface defines the following messages:
`Join-Req(mediated, SFI, Rec, OPT-
`REQ),
`
`where
`• mediated is a t1ag for mediation mode,
`SFI in the case of unicast-to-multicast scenario it is
`•
`the source IP address and the source port,
`• Rec is an IP address of a receiver;
`• OPT-REQ are additional preferences of a receiver
`(not elaborated here - empty).
`This is an incoming message (note, the message is
`defined in Table 1 on MGM-GCC interface). After
`receiving this message the MGM looks in its group
`management table to discover whether it is a new join,
`join. If it is a refreshment it restarts a
`or a refreshed
`refresh-timer for the join. If it is a new join, MGM has
`to decide first, whether the receiver is allowed to receive
`the required traffic (e.g. via examining policy cache).
`Then it looks for the entry with required SFI. If the
`entry exist, the new receiver will be added with its
`refresh-timer and the Join-Req-Ack message will be
`sent to the client. If the entry does not exist, the GAM
`module will be contacted to get a new private multicast
`address (GCA) and the GS module will be asked for a
`port (Dport) which should be used by receivers as
`destination ports.
`Join-Req message is sent by a host to a well known
`IP address of the MCM. MCM handles information
`about GCM groups in a cache. This cache is actually an
`extension of Multicast Address Resolution Table
`(MART), like in [7]. MCM cache is organised in entries
`with actual registration information for all hosts in a
`GCM group; each entry is indexed by a pair of IP Class
`
`•
`
`We consider the two cases below:
`•
`a host wishes to participate in both groups GCM(cid:173)
`enabled and native IP multicast for the same source,
`i.e. it requests explicitly to be in two different
`groups;
`a host wishes to be on a native IP multicast group
`but is unaware of the fact that this group's address
`is privately used in its GCM domain as a GCA
`(address clash could occur).
`In the same sub-network there could be receivers
`wishing to stay with native IP multicast, and those
`wishing to use GCM service, these two should be able
`to co-exist on the same machine. The problem arises
`from the fact that a router after receiving the IGMP
`report sets the state for the corresponding OIF and this
`state is anonymous with regard to receivers - it's a part
`of IP multicast service model and enhances scalability
`of native IP multicast.
`However after receiving IGMP request (periodically
`refreshed)
`all
`receivers generate
`reports which
`transmissions are suppressed for a random time. This
`time receivers are listening to other's reports. If heard
`before the local time-out expires. the local report is
`discarded, however the IGMP report state is kept in the
`IGMP module. By this every host on the subnet could
`know whether the subnet participates in particular
`multicast session.
`GCM client in a host when triggered by an application
`service request checks the subnet's state in its IGMP
`module and if this state is set, it creates a Join-Reg to
`GCM with subnet_state_for_session t1ag
`being set.
`MGM when receiving this request knows (by analysing
`the flag) that there might be a conflict between native
`enabled multicast
`and
`sets
`the
`and GCM
`state_fusion flag in GCM_request message to a
`router. Fig.
`6
`shows different behaviours
`in
`joining/leaving native IPMCA and GCMA.
`
`287
`
`CISCO EXHIBIT 1014
`Smirnov
`
`

`

`5
`
`Discussion
`
`In this section we want to highlight the benefits of our
`approach along
`the
`following guidelines already
`mentioned throughout the text:
`•
`Simplicity of the lightweight programmability vs
`active networks;
`Focus on deployment;
`•
`Incremental deployment;
`•
`• User and provider benefits.
`We also see possible drawbacks of the approach. We do
`not touch the issue of scalability because we have a
`feeling
`that group communication services
`in
`its
`majority will require scalable solutions in subnets while
`inter-domain infrastructure should grow from subnets'
`solutions (see below future work item on GCM
`federations). If a global group communication service is
`going to be proposed (most probably it will be a single
`source distribution) then its scalability features have to
`be addressed in particular.
`Another advantage of our approach will be clearly
`revealed by IPv6 deployment. Well designed scoping of
`IP multicast in IPv6 will allow fast and easy mapping of
`public multicast to private by just replicating a flow and
`distributing it within a domain with a domain wide
`scope.
`
`6
`
`Future work
`
`6.1
`
`Services around GCM
`
`One very evident candidate of a service which will
`benefit
`from GCM
`technology
`is authentication,
`authorisation and accounting service [15), which is even
`theoretically hard with the native IP multicast model.
`Another possible
`extension
`is provider policy
`enforcement on group communication.
`Finally, one should consider GCM as more active entity
`which also might
`trigger network management
`procedures, etc.
`
`6.2 GCM-GCM co-ordination
`
`It is also possible to build global group communication
`services based on GCM paradigm in local domains. One
`possible item of future research in this area would be to
`analyse how GCM domains should build mediated
`federations of GCM domains. It is possible for example
`to use BGMP
`to convey GCM
`information on
`federations.
`Another aspect is to investigate the possibility of
`Multicast Friendly eXchanges [16] to support federative
`GCM.
`
`Consider a host inside a GCM domain which is sending
`the IGMP join message for the IPMCA group in the
`native IP multicast mode. Edge router (designated IP
`multicast router for
`the subnet) checks with
`the
`established GCMF state in its forwarding path, whether
`the IPMCAjoined is in immediate use within the subnet
`as GCA. If NOT, the router does nothing and continues
`normal operation as specified for the inter-domain
`multicast protocol implemented. If YES, the router's
`control plane GCM functionality (Proxy) is triggered to
`send a lock_request message to the MGM, by
`which the router demands to exclude the IPMCA from
`
`the pool of Class D addresses privately managed in the
`GCM domain. The same operation is to be performed
`for all router's OIFs toward the GCM domain from
`which the IPMCAjoin has been received.
`
`Fig. 6 Joining/leaving
`concurrently
`
`IPMCA and GCMA
`
`Upon receipt of the lock_request the MGM locks
`the GCA in conflict, and checks with the private GCA
`pool whether this class D was already allocated for any
`GCM group. If NOT, the MGM just excludes the
`address from the private pool; if YES, the MGM checks
`whether the GCA in conflict has already been allocated
`and confirmed by a router1•
`If any router has this address already in use as a GCA
`then two design options can be evaluated:
`• Native IP multicast is considered to be a GCM
`group and is mapped locally to another GCA;
`• Native IP multicast in conflict is suspended until
`GCA in conflict is not re-mapped to another
`available GCA.
`Cl