One document matched: draft-ruiz-manet-mcast-gw-reqs-00.txt
Pedro M. Ruiz
Internet Draft Antonio F. Gmez-Skarmeta
Expires: July 2004 University of Murcia
January 2004
Requirements for MANET Interworking with Wired Multicast Networks
draft-ruiz-manet-mcast-gw-reqs-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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 July 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
A Mobile Ad hoc Network (MANET) is formed by the spontaneous
association of wireless and mobile devices capable of communicating
among them even when there is no networking infrastructure
available. Several unicast Internet gateway mechanisms have been
proposed within the IETEF MANET WG. However, the particular nature
of the IP Multicast model poses some additional requirements which
need to be satisfied by candidate solutions. This document aims at
identifying the requirements that a multicast solution for MANET
interworking with a fixed IP Multicast network should satisfy.
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 1]
Internet-Draft MANET mcast Interworking Requirements. January 2004
Table of Contents
Status of this Memo................................................1
Copyright Notice...................................................1
Abstract...........................................................1
1. Introduction and Motivation.....................................3
2. Terminology.....................................................4
3. IP Multicast in fixed IP Networks...............................4
4. Requirements....................................................4
4.1 Compatibility with wired IP Multicast protocols..............5
4.2 RPF-Compatible Address Management and scooping...............5
4.3 Multiple Gateway Support.....................................5
4.4 Compatibility with inter-domain multicast routing mechanisms.5
4.5 Independence on the multicast routing used the wired-side....5
4.6 Efficient routing within the MANET and low overhead..........6
4.7 Scalability..................................................6
4.8 Resilience and robustness....................................6
5. Specific issues to be considered................................6
6. Security Considerations.........................................8
References.........................................................9
Author's Addresses.................................................9
Intellectual Property Statement...................................10
Full Copyright Statement..........................................10
Acknowledgment....................................................11
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 2]
Internet-Draft MANET mcast Interworking Requirements. January 2004
1. Introduction and Motivation
IP Multicast communications are based on the idea of the source
sending only one packet with a group address as a destination. The
network will be in charge of replicating that packet only when
necessary to make it reach all the destinations. That is, all the
nodes that have joined the that specific group address. In addition,
the sources do not have to perform any operation prior to become
active sources for the multicast group.
The IP Multicast Model[1] defines the way in which IP Multicast is
supported in fixed networks. This model is based on three basic
assumptions:
1. IP Multicast sources just send IP datagrams addressed to a
Group IP address.
2. IP Multicast receivers use the IGMP (or MLD for IPv6) to join
an IP Multicast group and inform IP Multicast routers about
their interest in joining the group
3. Routers use IP Multicast routing protocols (e.g. PIM, DVMRP,
CBT, etc) to make IP Multicast traffic flow from the senders to
the receivers
Nowadays, the most usual combination of protocols being used in
fixed IP networks are IGMP and MLD for group memberships, PIM-SM for
intra-domain multicast routing and MSDP/MBGP for inter-domain IP
Multicast routing.
One of the challenges which is being dealt with within the IETF
MANET WG is the Internet connectivity for ad hoc networks. In fact,
there are some alternatives which have been already proposed [2, 3,
4, 5] both for IPv4 and IPv6 unicast connectivity. However, the
problem of IP Multicast connectivity for ad hoc networks deals with
a different paradigm which requires an smooth interworking with
existing protocols. In particular, there is a need for a clear
identification of requirements to be supported by candidate
solutions, given the special characteristics of the IP Multicast
model (e.g. PIM access routers need to be aware of any active IP
Multicast source so that receivers in other domains may join and
receive multicast packets from that source).
Different approaches may be followed in order to support an
integrated IP multicast traffic distribution between MANETs and
fixed IP networks. However, some of the alternatives may not be
compatible with the standard IP multicast model, or might not be
deployable in real networks. This document aims at identifying the
requirements that a multicast solution for MANET interworking with a
fixed IP Multicast network should satisfy, serving as a definition
of the particular issues that need to be considered when designing a
solution for that particular topic.
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 3]
Internet-Draft MANET mcast Interworking Requirements. January 2004
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [6].
3. IP Multicast in fixed IP Networks
To explain how does IP multicast work in fixed networks, we have to
comment on three different aspects: host-to-router signaling, intra-
domain routing protocols and inter-domain routing protocols.
Host-to-router signaling.
Nowadays, the standard host-to-router protocol used for group
membership is IGMPv2[7] (or MLD[8] for IPv6), which is implemented
in most of the common operating systems. Some IGMPv3 (and MLDv2)
implementations exist and are starting to be delivered with standard
operating system distributions.
Intra-domain multicast routing protocol.
There are several multicast routing protocols which have been
proposed for fixed networks. DVMRP has been the most widely used
since the deployment of the first multicast networks because of its
facilities to establish virtual multicast links, which formed the so
called MBone. However with the advent of native IP Multicast the
most widely supported and recommended IP multicast routing protocol
in the Internet is PIM-SM (or its IPv6-enabled variant).
Inter-domain multicast routing protocol.
For the inter-domain operation several protocols are used nowadays
in the Internet. On the one hand, MSDP is used for informing
neighbor domains about new active sources in our domain. On the
other hand, MBGP has been extended to carry not only unicast routing
information but also multicast, IPv6 and many other protocols
information among routing domains.
Thus, the currently used multicast approach is also known as: PIM-
SM/MSDP/MBGP. All these protocols operate in a very specific way
that imposes several requirements for being interoperable to the
multicast routing protocols used in MANETs. For example, PIM-SM
requires the first hop multicast router (FHMR) to encapsulate the
first packets sent by a source into PIM-Register messages, the router
running the MSDP process needs to be able to know when new sources
have come up in order to inform neighbor domains, etc. So, we should
carefully take into account the multicast model used in fixed
networks when designing and studying new approaches for multicast
MANET interworking with fixed IP networks.
4. Requirements
This section describes a list of requirement that should be
desirable to have in any candidate mechanism providing IP Multicast
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 4]
Internet-Draft MANET mcast Interworking Requirements. January 2004
interworking between MANETs and fixed IP networks (a.k.a. wired-
side).
4.1 Compatibility with wired IP Multicast protocols
The protocols used both within the MANET and in the wired-side MUST
be interoperable. For example, the multicast routing protocols used
in the Ad hoc network should be able to collaborate with those used
in the access network and in the core network to effectively build
multicast distribution topologies connecting every source
transmitting to a group G, with all the terminals joined to that
group regardless of their (ad hoc or Internet) point of attachment.
4.2 RPF-Compatible Address Management and scooping
The proper address management procedures MUST be provided so that
the addresses used by Ad hoc nodes attached to the Ad hoc extension,
could be also used by the fixed network routers to perform Reverse
Path Forwarding (RPF) checks or whatever multicast-related
procedures.
Efforts within the IETF towards automatic IP Multicast address
management, allocation and assignment such us MADCAP[9] should also
be considered when designing the proper multicast MANET address
management schemes.
In addition, routing approaches should be congruent with the
multicast mechanisms for creating scopes. That is, candidate
solutions should be able to support the network administrators in
confining the multicast traffic in specific regions. Nowadays two
scooping mechanisms have been defined: TTL scooping and
administratively scooping. The first limits the packets according to
the TTL value in the IP header while the latter uses different
address ranges and boundaries to confine the traffic addressed to
specific groups.
4.3 Multiple Gateway Support
Candidate solutions MUST offer mechanisms to deal with multiple
points of attachment to the wired-part. This functionality will
serve to improve the overall performance, load balancing, higher
reliability, etc.
4.4 Compatibility with inter-domain multicast routing mechanisms
Our solutions should not affect the inter-domain multicast routing
protocols being used in the administrative domain. In fact, the ad
hoc routing extensions should be implemented in such a way that
ensures that the information needed by these protocols could also be
extracted from the Ad hoc extension.
4.5 Independence on the multicast routing used the wired-side
The definition of the interoperation between fixed and ad hoc
extensions should be done in terms of functionality and information
that each part needs from the other. These rules SHOULD be generic
enough to guarantee that several routing approaches could be applied
in the wired-part.
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 5]
Internet-Draft MANET mcast Interworking Requirements. January 2004
4.6 Efficient routing within the MANET and low overhead.
In addition to offer a good interoperation with the fixed
infrastructure, the ad hoc routing mechanisms should be efficient
and effective in providing good routes between ad hoc nodes as well.
In fact, the routing protocols SHOULD still offer good routes even
when no nodes in the fixed network are taking part in the
communication and vice versa.
In addition, candidate solutions SHOULD not impose a high overhead
within the ad hoc network to prevent low-performance approaches. The
performance of the multicast ad hoc routing protocols should not be
significantly jeopardized. In fact, solutions demanding a high
signaling overhead are well-knonwn to produce a poor performance in
ad hoc network environments.
4.7 Scalability
The solution for making the ad hoc extension and the fixed
infrastructure protocols interoperable should preserve the basic
multicast principle of scalability to support a great amount of
users simultaneously. In particular, it SHOULD be interesting to
preserve the anonymous nature of IP multicast in which FHMRs do not
need to keep track on which are the members of any IP Multicast
group. Instead of that, they only need to know whether there is some
member for a particular group or not.
4.8 Resilience and robustness
These approaches should be robust enough to guarantee an effective
routing even when some control packets are lost, mobility creates
network loops and the points of attachment to the fixed network
dynamically change.
5. Specific issues to be considered
For multicast hosts the process of taking part in multicast
communications is quite straightforward. When they wish to send
multicast traffic they simply use a class-D address as a destination
and send the datagrams. When they are interested in receiving
multicast traffic, they use the Internet Group Management Protocol
(IGMP) as a request to their First Hop Multicast Router (FHMR). This
simple operation is not automatically supported in multicast ad hoc
routing protocols. So, in order to support the aforementioned
requirements, multicast ad hoc routing protocols are required to
deal with the following issues:
1) TTL related IGMP issues. IGMP assumes that multicast-enabled
routers and its end-nodes are all directly connected through the
link layer without any intermediate router. Thus, the communication
between the First Hop Multicast router (FHMR) and the end nodes is
performed by means of packets having a TTL of one. That is, IGMP
messages cannot traverse routers unless some tunneling mechanism or
IGMP-proxy is implemented. This limitation applies both for IGMP
reports coming from the end-nodes towards the FHMR and for IGMP
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 6]
Internet-Draft MANET mcast Interworking Requirements. January 2004
Queries coming from the FHMR towards the end-nodes. So, the correct
placing of FHMRs in our architecture may very much influence both
the mechanisms to deploy and the efficiency that we can achieve with
our approach.
2) Shared medium related IGMP issues. The Internet Group Management
Protocol (IGMP) was specially designed for shared medium networks in
which one frame sent by a node can be received by all other nodes
connected to the same link layer. In fact, this assumption is used
by IGMP to optimize its behavior. So, as long as the router is only
interested in knowing if there is any node interested in receiving a
multicast group, when one of the interested nodes replies to the
router with an IGMP report message, the other interested nodes do
not need to reply again. The shared medium is what ensures that
other nodes are going to be able to know that there have been other
answers. This is used both in IGMPv1 and IGMPv2. The good point is
that IGMPv3 do not need this approach to be followed. In addition,
not following this approach does not break IGMP but only makes it
less optimal in bandwidth usage. However this is not an issue in the
currently deployed switched networks.
3) Tunneling of IGMP messages. The tunneling of IGMP messages to
overcome its TTL limitation does not tend to be the better approach
for scarce resources networks like Ad hoc extensions to a fixed IP
Network. This kind of solutions usually led to inefficient data
distribution as well as scalability problems. The protocol
efficiency is damaged by means of using extra headers due to the
tunneling process. The protocol scalability is also damaged by means
of making the FHMR to become a single point of failure. However, the
worse problem is that the FHMR has to store individual membership
for every end-node instead of forwarding state of the interface. In
addition the FHMR has to send a copy of each datagram to each end-
node instead of sending just one datagram to the shared medium. The
same limitation applies for datagrams from one of those end-nodes to
the rest of end-nodes in the same network. In this case the FHMR has
to redistribute these datagrams between all these nodes, which is
not the proper multicast behavior.
4) Uplink and downlink support. The requirements and mechanisms
needed to support multicast communications both from end terminals
to fixed nodes in the core network and vice versa are different. So,
in the following subsections we will need to study both approaches
for every option. In general, sending multicast datagrams do not
impose any requirement to the end-node but the ad hoc routing
protocol should behave so that one router in the fixed IP network
running PIM-SM should be able to detect such traffic and send it to
the RP encapsulated in a PIM-Register message. For receiving, the
end-node needs to inform the routers about the groups it wants to
join and the ad hoc routing protocol should ensure that some PIM-SM
router in the BAN will detect that need and join the proper
multicast tree towards the RP.
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 7]
Internet-Draft MANET mcast Interworking Requirements. January 2004
5) Supporting roaming of terminals from and to the ad hoc network.
Using IGMP for group management in the wired network is the standard
way to work. However, we should also ensure that Standard-IP nodes
use the same group management protocol so that they could operate in
the same way when they are attached to the wired network as well as
when they are in the Ad hoc extension. Otherwise, Standard-IP nodes
would have to implement several group management protocol stacks.
6. Security Considerations
Security requirements are not included in this version of the
Internet-Draft. They will be added in future revisions.
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 8]
Internet-Draft MANET mcast Interworking Requirements. January 2004
References
[1] Steve Deering. Host extensions for IP multicasting. RFC 1112,
August 1989.
[2] Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A. and A.
Tuominen, "Internet Connectivity for Mobile Ad hoc networks",
I-D draft-wakikawa-manet-globalv6-02.txt, November 2002.
[3] Perkins, C., Belding-Royer, E. and I. Chakeres, "Internet
Connectivity for Mobile Ad hoc networks", I-D draft-perkins-
manet-aodvbis-00.txt, October 2003
[4] C. Jelger, T. Noel, Gateway and address autoconfiguration
for IPv6 ad-hoc networks, I-D draft-jelger-manet-gateway-
autoconf-v6-01.txt. Work in progress. October, 2003.
[5] H. Cha, J. Park, H. Kim, Extended Support for Global
Connectivity for IPv6 Mobile Ad Hoc Networks, I-D draft-cha-
manet-extended-support-globalv6-00.txt. Work in progress.
October, 2003.
[6] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March, 1997.
[7] W. Fenner, Internet Group Management Protocol, Version 2.
RFC 2236, November 1997.
[8] S. Deering, W. Fenner, B. Haberman, Multicast Listener
Discovery (MLD) for IPv6. RFC 2710, October, 1999.
[9] Hanna, S., Patel, B. and Shah, M.: Multicast Address Dynamic
Client Allocation Protocol (MADCAP), RFC 2730, December 1999
Author's Addresses
Pedro M. Ruiz
Dpto. Ingeniera de la Informacion y las Comunicaciones
University of Murcia
Facultad de Informatica
Campus de Espinardo s/n
E-30100 Murcia (Spain))
Phone: +34 968367646
Email: pedrom@dif.um.es
Antonio F. Gomez-Skarmeta
Dpto. Ingeniera de la Informacion y las Comunicaciones
University of Murcia
Facultad de Informatica
Campus de Espinardo s/n
E-30100 Murcia (Spain)
Phone: +34 968364607
Email: skarmeta@dif.um.es
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 9]
Internet-Draft MANET mcast Interworking Requirements. January 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 10]
Internet-Draft MANET mcast Interworking Requirements. January 2004
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society. In addition, part of this work is funded by the
Spanish MCYT.
Ruiz, Gomez-Skarmeta. Expires June 2004 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 03:56:26 |