[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                    Keyur Patel
Internet Draft                                           Cisco Systems
Expiration Date: April 2004                              Radia Perlman
                                                         Sun Microsystems
                                                         Dino Farinacci
                                                         Greg Shepherd
                                                         Procket Networks
                                                         Marshall Eubanks
                                                         Multicast Technologies

                   Automatic Multicast Access Protocol

                          draft-keyur-amap-00.txt


1. 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.


2. Abstract

   This document describes a new multicast signaling protocol for
   solving the "last-mile connectivity" problem for multicast. This
   protocol is called Automatic Multicast Access Protocol (AMAP). It
   is intended to facilitate an endnode that resides in a portion of
   the Internet infrastructure without multicast support, or whose OS
   does not support IGMPv3 (SSM stype groups).


3. Introduction

   An impediment to getting end-to-end multicast connectivity is that,
   currently, ISPs seldom enable multicast routing within an entire
   AS. This makes end-to-end multicast content provision difficult,
   particularly with respect to Last Mile Multicast.

   This document proposes a new multicast signaling protocol known as
   Automatic Multicast Access Protocol (AMAP) which allows endnodes
   residing in portions of the Internet infrastucture without any
   multicast support to join multicast groups. AMAP allows endnodes
   which run multicast applications to get the efficiencies of a
   multicast enabled infrastructure without being directly attached
   to such an infrastructure. This is achieved using a tunneling mechanism.
   As the multicast infrastructure deployment moves towards the edge of
   the network, the tunnel diameter is reduced to a point where it is
   either minimised or no longer needed.

   AMAP could be used for both SSM as well as ASM style multicast.
   For endnodes residing in a portion of the Internet without any support
   for multicast, this mechanism could be used for ASM groups by using
   a Replicator address in place of an explicit root address. A

Patel, Perlman, Farinacci, Shepherd, Eubanks                    [Page 1]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


   Replicator address is an address of a router which serves as a tunnel
   endpoint for all/set of receivers within an AS. A well known anycast
   address, which is a valid unicast address assigned to multiple routers
   to get "closest replicator capability" defined by IANA, can be used as
   a Replicator address within an AS.

   Any router that does not support this protocol will simply unicast
   forward the messages according to the rules for forwarding a packet with
   the Router Alert set. The first multicast capable router that supports
   AMAP will notice these messages and may form a tunnel with the endnode
   that generated the message.


4. AMAP Messages

   This section defines different message formats for AMAP. AMAP messages
   are sent unicast to a particular source or an endnode, or towards a
   Replicator address. AMAP messages are sent as IP protocol type = "UDP"
   with the port number TBD by IANA.

   An implementation of AMAP must support all the message types described
   below. Any unrecognized messages should be logged with a fatal warning.
   Each AMAP message has a fixed size header. The layout of this header is
   shown below:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ver   | Res   |      Type     |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   AMAP Ver
     AMAP Version number is 1.

   Reserved
     Set to zero on transmission.  Ignored upon receipt.

   Type
     Types for specific AMAP messages.  AMAP Types are:


     Message Type                Source            Destination
     -------------------------------------------------------------------------
     0 = Query Message           Router            Unicast to Endnodes
     1 = Join Message            Endnode           Unicast to Source/
                                                   Replicator address
     2 = Join-Ack Message        Router            Unicast to Endnodes
     3 = Auth Ack                Router/Endnode    Unicast to Source/Endnodes
     4 = Prune Message           Router/Endnode    Unicast to Source/Endnodes
     5 = Prune-Ack Message       Router/Endnode    Unicast to Source/Endnodes
     6 = Data Message            Router            Unicast to Endnodes
     7 = Notification Message    Router/Endnode    Unicast to Source/Endnodes

   Checksum
     The checksum is a standard IP checksum, i.e.  the 16-bit one's
     complement of the one's complement sum of the entire AMAP message.
     For computing the checksum, the checksum field is zeroed.

     For IPv6, the checksum also includes the IPv6 "pseudo-header", as
     specified in RFC 2460, section 8.1 [5]. This "pseudo-header" is
     prepended to the AMAP header for the purposes of calculating the
     checksum.  The "Upper-Layer Packet Length" in the pseudo-header is
     set to the length of the AMAP message.  The Next Header value used
     in the pseudo-header is 103.  If the packet's length is not an
     integral number of 16-bit words, the packet is padded with a byte
     of zero before performing the checksum.

   Encoded format for Unicast Source and Group address is shown below:

Patel, Perlman, Farinacci, Shepherd, Eubanks                    [Page 2]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Addr Family  | Encoding Type |     Unicast Address
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

   Addr Family
     The AMAP address family of the 'Unicast Address' field of this
     address.

     Values of 0-127 are as assigned by the IANA for Internet Address
     Families in [8]. Values 128-250 are reserved to be assigned by the
     IANA for PIM-specific Address Families.  Values 251 though 255 are
     designated for private use.  As there is no assignment authority
     for this space, collisions should be expected.

   Encoding Type
     The type of encoding used within a specific Address Family.  The
     value `0' is reserved for this field, and represents the native
     encoding of the Address Family.

   Unicast Address
     The unicast address as represented by the given Address Family and
     Encoding Type.

4.1  AMAP Router Query message format

   Query messages are sent by AMAP routers to its tunnel endpoints
   for periodic refresh of their multicast state.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Unicast Router address  (Encoded-Source format)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Unicast Router Address
     Unicast address of an AMAP router generating Query messages. For
     format description refer to Encoded-Unicast address.

4.2  AMAP Host Join message format

   Host Join messages are sent to assist building and maintainence of tunnel
   states for (S/*, G) entries. Host Join messages are sent by endnodes
   towards a Source address/Replicator address. For all (S, G) Host Join
   messages, the Multicast Source Address will have a non-zero unicast
   address field. For all (*, G) Host Join messages, the Multicast
   Source Address will have a zero unicast address field. AMAP
   implementations are suggested to send seperate Host Join messages for
   (S, G) and (*, G) entries.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     | Num Jn groups |          Holdtime             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tn Format    | Replicator Address  (Encoded format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Multicast Source Address (Encoded-Group format)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address 1 (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             .                                 |
     |                             .                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address n (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Variable length TLVs                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Patel, Perlman, Farinacci, Shepherd, Eubanks                    [Page 3]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


   Reserved
     Transmitted as zero, ignored upon receipt.

   Number of Join Groups
     The number of multicast group sets contained in the message.

   Holdtime
     The amount of time a receiver must keep the tunnel state alive
     in seconds.  If the Holdtime is set to `0xffff', the receiver of
     this message should hold the state until canceled by the
     Prune message, or timed out according to local policy.  This may be
     used with dial-on-demand links, to avoid keeping the link up with
     the periodic Join or Prune messages.

   Tunnel Type
     A specific type of tunnel that an endnode wants to use with an AMAP
     Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload).

   Replicator address
     Address assigned to an AMAP router. When used in anycast-mode, it is an
     address assigned to multiple AMAP routers to get "closest replicator
     capability". For format description refer to Encoded-Unicast address.

   Multicast Source address
     Sender address that the endnode is interested in receiving data from.
     For format description refer to Encoded-Unicast address.

   Join Group Address 1 .. n
     This list contains the Groups that the endnode is interested in receiving
     data from. For format description refer to Encoded-Unicast address.

   Variable length TLVs
     The Encoded format for TLVs is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Capabilities                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
     A 16 bit field set to 1.

   Length
     A 16 bit field that indicates the length of the value portion in bytes.

   Capabilities
     This comprises one or more capability values.

4.3  AMAP Router Join-Ack message format

   Router Join-Ack messages are sent to acknowledge the receipt of
   the Host Join message by AMAP routers.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     | Num Jn groups |          Holdtime             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Tn Format    | Multicast Source Address  (Encoded format)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address 1 (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             .                                 |
     |                             .                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address n (Encoded-Group format)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Cookie Value                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Variable length TLVs                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Patel, Perlman, Farinacci, Shepherd, Eubanks                    [Page 4]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


   Reserved
     Transmitted as zero, ignored upon receipt.

   Number of Join Groups
     The number of multicast group sets contained in the message.

   Holdtime
     The amount of time a receiver must keep the tunnel state alive
     in seconds.  If the Holdtime is set to `0xffff', the receiver of
     this message should hold the state until canceled by the
     Prune message, or timed out according to local policy.  This may be
     used with dial-on-demand links, to avoid keeping the link up with
     the periodic Join or Prune messages.

   Tunnel Type
     A specific type of tunnel that an endnode wants to use with an AMAP
     Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload).

   Multicast Source address
     Sender address that the endnode is interested in receiving data from.
     For format description refer to Encoded-Unicast address.

   Join Group Address 1 .. n
     This is an accepted list of Groups for which the sending router may
     establish tunnel connection with an endnode. For format description
     refer to Encoded-Unicast address.

   Cookie Value
     Router cookie value that is reflected back in Auth-Ack message.

   Variable length TLVs
     See Encoded-TLV format.

4.4  AMAP Prune message format

   Prune messages are sent to terminate existing tunnel connections for
   (S/*, G) entries. Prune messages are sent by endnodes/AMAP routers
   towards a source/replicator address or an endnode address.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     |          Holdtime             |  Tn Format    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Replicator Address  (Encoded format)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Multicast Source Address (Encoded-Group format)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address (Encoded-Group format)            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved
     Transmitted as zero, ignored upon receipt.

   Holdtime
     The amount of time a receiver must keep the tunnel state alive
     in seconds.  If the Holdtime is set to `0xffff', the receiver of
     this message should hold the state until canceled by the
     Prune message, or timed out according to local policy.  This may be
     used with dial-on-demand links, to avoid keeping the link up with
     the periodic Join or Prune messages.

   Tn Format
     A specific type of tunnel that an endnode wants to use with an AMAP
     Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload).

   Replicator address
     Address assigned to an AMAP router. When used in anycast-mode, it is an
     address assigned to multiple AMAP routers to get "closest replicator
     capability". For format description refer to Encoded-Unicast address.

   Multicast Source address
     For format description refer to Encoded-Unicast address.

Patel, Perlman, Farinacci, Shepherd, Eubanks                    [Page 5]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


   Prune Group Address
     Group address to be pruned. For format description refer to
     Encoded-Unicast address.

4.5  AMAP Prune-Ack message format

   Prunes-Ack messages are sent to acknowlege the receipt of
   the Prune messages.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     |        Holdtime               | Tn Format     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Replicator Address  (Encoded format)                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Multicast Source Address (Encoded-Group format)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address  (Encoded-Group format)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Cookie Value                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved
     Transmitted as zero, ignored upon receipt.

   Holdtime
     The amount of time a receiver must keep the tunnel state alive
     in seconds.  If the Holdtime is set to `0xffff', the receiver of
     this message should hold the state until canceled by the
     Prune message, or timed out according to local policy.  This may be
     used with dial-on-demand links, to avoid keeping the link up with
     the periodic Join or Prune messages.

   Tn Format
     A specific type of tunnel that an endnode wants to use with an AMAP
     Router: 0 (IP-in-IP), 1 (GRE type 0x800 carrying IPv4 as a payload).

   Replicator address
     Address assigned to an AMAP router. When used in anycast-mode, it is an
     address assigned to multiple AMAP routers to get "closest replicator
     capability". For format description refer to Encoded-Unicast address.

   Multicast Source address
     Sender address to be pruned. For format description refer to
     Encoded-Unicast address.

   Prune Group Address
     This contains the Group address to be pruned. For format description
     refer to Encoded-Unicast address.

   Cookie Value
     Sender's cookie value that is reflected back in an Auth-Ack message.

4.6  AMAP Host Auth-Ack message format

   Auth-Ack messages are sent to acknowledge the receipt of a Join-Ack message
   or a Prune-Ack message.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Reserved     | Prune/Join    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Cookie Value                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Prune-Ack/Join-Ack message                 /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved
     Transmitted as zero, ignored upon receipt.

Patel, Perlman, Farinacci, Shepherd, Eubanks                    [Page 6]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


   Prune/Join
     Auth message sent in respone to 0 (Join-Ack) 1 (Prune-Ack).

   Cookie Value
     Sender's cookie value that is reflected back in Auth-Ack message.

   Prune-Ack/Join-Ack message
     Received AMAP Prune-Ack message/Join-Ack message triggering the Auth-Ack
     message.


4.7 AMAP Notification message format

   Notification messages are sent either by an AMAP router or an endnode
   intiating a tunnel connection.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type         |    Subtype    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Multicast Source Address (Encoded-Group format)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Joined Group Address  (Encoded-Group format)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Destination Cookie Value   (Optional)            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Source Cookie Value  (Optional)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Type/Subtype
      AMAP Notification message are of following types:
      Type:           1       Error Message
      Subtype:        1       Incorrect Version Number
                      2       Incorrect Cookie Value
                      3       Incorrect Message Type
                      4       Incorrect Address Encoding format
                      5       Incorrect Message Length
                      6       Unrecognised Route Entry Pruned
                      7       Unrecognised Capability
                      8       Incorrect Capability length
                      9       Incorrect Tunnel format
                      10      Incorrect Destination

   Multicast Source address
     Multicast Source address for which the Notification is sent.
     For format description refer to Encoded-Unicast address.

   Prune Group Address
     Multicast Group address for which the Notification is sent.
     This contains the Group address to be pruned.

   Destination Cookie Value
      Destination receiving Notification message's Cookie value. This
      field is optional

   Source Cookie Value
      Source generating Notification message's Cookie value. This field
      is optional.

   All Notification messages must be logged. An implementation can
   choose to terminate tunnel connections for (S/*, G) route entries for
   which a Notification message received has cookie values successfully
   verified.


5. Protocol Description for Endnodes

   AMAP has a seperate protocol behavior for endnodes initiating
   the tunnel connections to join multicast (S/*, G) channels and AMAP
   routers terminating tunnel connections. This section describes the
   protocol behavior for the endnodes initiating the tunnel connections.

Patel, Perlman, Farinacci, Shepherd, Eubanks                    [Page 7]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


5.1 Generating Join Messages

   There are two main events that trigger generation of the Join messages
   for initiating (S/*, G) tunnel connections:

   * Applications residing on an endnode wanting to join a particular/set of
   (S/*, G) groups.

   * Reception of a Query message.

   The following subsections describe actions to be taken for each of the
   above cases.

5.1.1 Applications triggering a Join message

   Whenever an endnode running multicast applications in a  non-multicast
   network wishes to join a particular (S/*, G) channel, it signals AMAP
   with relevant parameters: (S/*, G) sets, a Replication address, and a
   configured cookie value.

   AMAP schedules a Join-expire timer with a configured/(default holdtime
   interval)/3. AMAP creates an appropriate Join message and sends it
   towards a Replication address if specified, or the Source address.

5.1.2 Reception of a Query message

   Whenever an endnode running AMAP receives a Query message, it processes
   the message. It verifies the querier's router address with the stored router
   address in the tunnel interface information. It [re-]schedules the
   Join-expire timer to the join-expire interval. The suggested default
   value for the join-expire interval is set to the AMAP router's (Holdtime
   interval)/3 (received in a Join-Ack message). It also [re-]schedules the
   query-expire timer to an query-expire interval. The suggested default
   value for the query-expire interval is set to the AMAP router's (Holdtime
   interval)/3 (received in a Join-Ack message). It then sends a Join
   message for all (S/*, G) entries for which the querier acts as a
   tunnel endpoint.

5.2 Generating Prune message

   Whenever a particular (S/*, G) channel is no longer required, a Prune
   message is sent to the tunnel endpoint. An endnode running AMAP schedules
   the Prune-expire timer to the prune-expire interval. The suggested
   default value for the prune-expire interval is set to the AMAP router's
   (Holdtime interval)/3 (received in a Join-Ack message). It then sends a
   Prune message for a (S/*, G) channel to the AMAP router that acts as a
   tunnel endpoint.


5.3 Generation of an Auth-Ack message

   Auth-Ack message is sent in response to the received Join-Ack message or
   a Prune-Ack message. An Auth-Ack message is sent with the cookie value
   received in a Join-Ack/Prune-Ack message from the AMAP router. Tunnel
   connection is either considered functional (if sent in response to
   the Join-Ack message) or deleted (if sent in response to the Prune-Ack
   message) once an Auth-Ack message is sent by an endnode to the AMAP router.

5.4 Reception of Data message

   Data messages are encapsulated in an negotiated tunnel format by AMAP
   routers. Whenever an endnode receives a data message, its encapsulated
   format is verified with the stored negotiated format. If the tunnel format
   differs, then a Notification message is sent and the tunnel connection is
   terminated. Otherwise, data packets received are decapsulated and sent
   to appropriate applications.

Patel, Perlman, Farinacci, Shepherd, Eubanks                    [Page 8]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


5.5 Reception of Prune message

   Whenever an endnode receives a Prune message for a given (S/*, G) entry
   from an AMAP router, it checks to verify if the sending AMAP router is
   acting as a tunnel endpoint. In case of an error, the Prune message is
   ignored and a Notification message is sent to an AMAP router. Otherwise,
   the PruneAck-expire timer is scheduled for the prune-expire interval and
   a Prune-Ack message is sent to an AMAP router. An endnode cookie is passed
   in the Prune-Ack message.

5.6 Reception of an Auth-Ack message

   An Auth-Ack message is received in response to any Prune-Ack message sent
   by an endnode. Whenever an endnode receives an Auth-Ack message, it
   processes the message. It verifies cookie values sent within an
   Auth-Ack message. In the event of an error, a Notification message is
   sent and an Auth-Ack message is ignored. Otherwise, the
   PruneAck-expire timer is stopped for all (S/*, G) entries mentioned
   in the Auth-Ack message. At this point the tunnel is disconnected and
   the state is removed as described in [6.7].

5.7 Timer expiry

   In the event of a join-expire, prune-expire, or a query-expire timeout, a
   Notification message is sent and the tunnel connection is disconnected.


6. Protocol Description for AMAP Routers

   This section describes the protocol behavior for AMAP routers. Multicast
   routers implementing AMAP will process Join messages according
   to rules defined in this specification even when the IP destination
   address is not assigned to the router. To allow a router to
   recognize AMAP messages addressed to the unicast root address, and
   place it on the slow path, rather than simply forwarding it towards
   the specified destination, Join messages will have the router alert
   option, and the IP protocol type="UDP" with port number TBD by IANA.

6.1 Reception of a Join message

   Whenever an AMAP router intercepts a Join message it verifies them with
   its locally configured policies. If the locally configured policies
   disallow the router from intercepting Join messages, then it
   simply forwards the message towards the destination. All the multicast
   routers forwarding AMAP packets towards the desired destination must
   use unicast RIB to resolve destination address. Otherwise, the
   intercepting router processes the received Join message. In the
   event of an error, the intercepting router should drop the received
   Join message and send a Notification message to an endnode. Otherwise,
   the intercepting router schedules a JoinAck-expire timer for join-expire
   interval and sends a Join-Ack message to the endnode. The suggested
   default value for the join-expire interval is set to the endnode's
   (Holdtime interval)/3 (received in a Join message). A router based cookie
   value is sent in the Join-Ack message.

   In an event where an AMAP router processes and resolves a subset of the
   (S/*, G) entries received in a Join message, the AMAP router should send a
   Join-Ack message for only those entries which are resolved. For all
   unresolved (S/*, G) entries, the AMAP router forwards them towards the
   direction of the Source address/Replication address in the IP destination
   of the Join message.

6.2 Reception of a Prune message

   Whenever an AMAP router receives a Prune message for a given (S/*, G)
   entry, it checks to verify if the sending endnode is a tunnel endpoint.
   In case of an error the Prune message is ignored and a Notification message
   is sent to an endpoint. Otherwise, the PruneAck-expire timer is scheduled

Patel, Perlman, Farinacci, Shepherd, Eubanks                    [Page 9]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


   for the prune-expire interval and the Prune-Ack message is sent to an
   endnode. The suggested default value for the Prune-expire interval is
   set to the endnode's (Holdtime interval)/3 (received in a Prune message).
   A router based cookie value is sent in the Prune-Ack message.

6.3 Reception of an Auth-Ack message

   Auth-Ack messages are received in response of:

   * AMAP router's Join-Ack message sent

   * AMAP router's Prune-Ack message sent

   The following subsections describe actions to be taken for each of the
   above cases.

6.3.1 Auth-Ack message in response of a Join-Ack message

   Whenever an AMAP router receives an Auth-Ack message, it processes the
   message. It verifies cookie values sent within an Auth-Ack message. In
   the event of an error, a Notification message is sent and an Auth-Ack
   message is ignored. Otherwise, the JoinAck-expire timer is stopped for
   all (S/*, G) entries mentioned in the Auth-Ack message. This signals the
   successful completion of the tunnel signaling between an endnode intiating
   the tunnel connection and an AMAP router terminating the tunnel
   connection. At this point the tunnel is setup and the state is
   created as described in [6.7]. An AMAP router starts to send multicast
   packets over the tunnel.

6.3.2 Auth-Ack message in response of a Prune-Ack message

   Whenever an AMAP router receives an Auth-Ack message, it processes the
   message. It verifies cookie values sent within an Auth-Ack message. In
   the event of an error, a Notification message is sent and an Auth-Ack
   message is ignored. Otherwise, the PruneAck-expire timer is stopped for
   all (S/*, G) entries mentioned in the Auth-Ack message. At this point
   the tunnel is disconnected and the state is removed as described in [6.7].
   An AMAP router stops sending multicast packets over the tunnel for all
   (S/*, G) entries metioned in the Auth-Ack message.


6.4 Generation of an Auth-Ack message

   Auth-Ack message is sent in response to the received Join-Ack message or
   a Prune-Ack message. An Auth-Ack message is sent with the cookie value
   received in the Join-Ack/Prune-Ack message from the AMAP router. The
   tunnel connection is either considered functional (if sent in response to
   a Join-Ack message) or deleted (if sent in response to a Prune-Ack
   message) once an Auth-Ack message is sent by an endnode to the AMAP router.

6.5 Generating a Prune message

   AMAP routers can generate Prune messages whenever they loose upstream
   connectivity or due to some local policy reasons. An AMAP router schedules
   the Prune-expire timer to the prune-expire interval. The suggested
   default value for the prune-expire interval is set to endnodes's
   (Holdtime interval)/3. It then sends a Prune message for (S/*, G) entry
   to all/a subset of endnodes listed in the oif-list of (S/*, G) entry.

6.6 Generating a Query message

   AMAP routers acting as a tunnel endpoint for various (S/*, G) entries
   will periodically query all its interested tunnel endnodes by sending a
   Query message. An AMAP router sends Query messages every query-expire
   interval. The suggested default for the query-expire interval is set
   to an endnode's (Holdtime interval)/3 (received in a Join message).
   AMAP routers keeps track of all the tunnel destinations (regardless if
   the tunnel destination is joined to one or more route entries).

Patel, Perlman, Farinacci, Shepherd, Eubanks                   [Page 10]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


   Any (S/*, G) entries not refreshed by the endnodes in their Join
   messages sent in response to Query messages within a join-expire
   interval will be immediately dropped. This assists AMAP routers sending
   the Query messages and endpoints replying with the Join messages to detect
   any unwanted tunnel breakages.

   The holdtime used in Join messages and Join-Ack messages determines the
   maximum waiting time that an AMAP router and an endnode should
   wait before terminating a tunnel at each end. If an endnode fails to
   receive a Query message for more than the Holdtime interval advertised
   by an AMAP router in its Join-Ack message, then it terminates and
   re-initiates tunnel connection. Similarly if the Join messages are not
   received for more than the Holdtime interval advertised in the previous
   Join message, then the router removes the tunnel interface from its
   (S/*, G) entries.

   Any (S/*, G) entries created with a holdtime value of '0xffff' need not be
   refreshed periodically using Query messages. Such (S/*, G) entries can
   only be explicitly removed using Prune messages or timed out using local
   policies.

6.7 Reception of Data messages

   Data messages are either received as native multicast, or as encapsulated
   in a negotiated tunnel format. Whenever an AMAP router receives
   encapsulated data messages, its encapsulated format is verified with
   the stored negotiated format. If the tunnel format differs, then the
   Notification message is sent and tunnel connection is terminated.

   If an (S/*, G) entry exists for data messages received, then the messages
   are encapsulated with a negotiated tunnel format and forwarded to all
   the AMAP tunnel endpoints listed in the oif-lists. Otherwise, data
   messages are dropped and a Prune message is sent to the upstream
   router.

6.8 Timer expiry

   In the event of join-expire, prune-expire, or a query-expire timeout, a
   Notification message is sent and the tunnel connection is disconnected.

6.9 State Creation and Deletion

   AMAP routers will add the tunnel interfaces [8] in its (S/*, G) oif-lists
   when it receives an Auth-Ack message in response to a Join-Ack message
   from the endnodes. An implementation must have a configured upper bound
   on the number of the tunnel interfaces that it can put in oif-lists of
   any (S/*, G) entry.

   If a tunnel interface added is the first interface in an oif-list, and if
   Multicast router has PIM enabled, then the PIM Protocol should be
   signaled for generation of a PIM Join message.

   AMAP routers will delete the tunnel interfaces from their (S, G)
   oif-lists when:

   * It receives an Auth-Ack message in response to a Prune-Ack messages
   from endnodes.

   * Any of the Join-expire, or Prune-expire, timers for the tunnel interfaces
   expire and its state is not refreshed.

   * If a Join message (in reponse to a Query message) is not received
     within a Holdtime interval.

   * If a Query message is not received from a tunnel endpoint within
     a query-expire interval.

   * AMAP routers sends an Auth-Ack message in response to a Prune-Ack
   message received from endnodes.

Patel, Perlman, Farinacci, Shepherd, Eubanks                   [Page 11]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


6.10 Signaling and Forwarding Rules:

   Whenever multicast routers implementing AMAP receive Join messages
   from any endnodes, the following is done:

   The received (S/*, G) entry is looked up in the Multicast
   Routing Table. If the entry does not exist, then the (S/*, G) entry
   is created.

   * If a Join message or a Prune message has a non-zero Source address,
   (i.e (S, G) and not (*, G)) then the next hop for the Source address check
   is done. If the next hop is a PIM neighbor, or it is directly connected
   (and PIM enabled) then a JoinAck-expire timer is scheduled for the
   join-expire interval and a Join-Ack message is sent to an endnode.


   * If the next hop is neither a PIM neighbor nor directly connected,
   then the packet is forwarded towards the ip destination address. If the
   (S/*, G) entry was created as a result of a lookup, then delete the
   (S/*, G) entry from the Multicast Routing Table.

   * If there is no source address (i.e (*, G)), then check for the group
   mapping in the RP cache. If the group mapping is found for a particular
   entry then schedule a JoinAck-expire timer for the join-expire interval
   and send a Join-Ack message to an endnode. Otherwise, forward the Join
   message towards the ip destination address. If the (*, G) entry was
   created as a result of lookup, then delete the (*, G) entry from the
   Multicast Routing Table.

   Whenever Multicast routers implementing AMAP receive an Auth-Ack message
   for a Join message, the following is done:

   * Stop the JoinAck-expire timer.

   * Add the tunnel interface to the Outgoing Interface List (oif-list) of
   (S/*, G) entry.

   * For all (S, G) route entries, signal PIM to send a PIM Join message
   towards the Source address if PIM is enabled.

   * For all (*, G) route entries, signal PIM to send a PIM Join message
   towards the RPL address if PIM is enabled.

   Whenever multicast routers implementing AMAP receive Prune messages
   from any endnodes, the following is done:

   The received (S/*, G) entry is looked up in the Multicast Routing Table.
   If the entry does not exist, then a Notification message is sent for
   the received (S/*, G) entry.

   * If the entry is found, then a PruneAck-expire timer is scheduled for
   the prune-expire interval and a Prue-Ack message is sent to an endnode.

   Whenever multicast routers implementing AMAP receive an Auth-Ack message
   for Prune messages, the following is done:

   The received (S/*, G) entry is looked up in the Multicast Routing Table.
   If the entry does not exist, then a Notification message is sent for
   the received (S/*, G) entry.

   * Stop the PruneAck-expire timer.

   * Remove the tunnel interface to the Outgoing Interface List (oif-list) of
   (S/*, G) entry.

   * For all (S, G) route entries, signal PIM to send a PIM Prune message
   towards the Source address if PIM is enabled.

   * For all (*, G) route entries, signal PIM to send a PIM Prune message
   towards the RPL address if PIM is enabled.

Patel, Perlman, Farinacci, Shepherd, Eubanks                   [Page 12]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


6.11 Aggregation
    TBD

6.12 Tunnel Chaining
    TBD


7. AMAP Message Processing

7.1 Router receiving AMAP Join message

    Endnode                               Router
    -------                               ------
    Send AMAP Join   ------------------>  Receive AMAP Join message
    message for
    interested (S, G)
    groups
                                          if (error in message processing)
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Appropriate Message Error
                                                Code"


                                          For each (S, G) received entry,

                                          Lookup (S, G) entry.

                                          if (entry found) {

                                             schedule Join-expire Timer
                                             for a received interface

                                             if (cookie value != old cookie
                                                 value) {

                                                 store the received cookie
                                                 value
                                             }

    Receive AMAP Join-Ack <-------------     send AMAP Join-Ack message
    message                                  with router cookie value

                                          } else {

                                          create (S, G) entry

                                          Nexthop Lookup for (S).

                                          if ((S == Pim Nbr) ||
                                               (S == directly connected) {

                                               schedule Join-expire Timer
                                               for a received interface

                                               store the received cookie value

    Receive AMAP Join-Ack <-------------       send AMAP Join-Ack message
    message                                    with router cookie value

                                          } else if (!S &&
                                          group mapping found in RP Cache) {

                                               schedule Join-expire Timer
                                               for a received interface

                                               store the received cookie value

    Receive AMAP Join-Ack <-------------       send AMAP Join-Ack message
    message                                    with router cookie value

Patel, Perlman, Farinacci, Shepherd, Eubanks                   [Page 13]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


                                          } else if (destination in IP (!local
                                                     interface)) {

                                                stop the Join-expire Timer

                                                if (multicast enabled) {

                                                   lookup in MRIB and

                                                   forward the Join towards
                                                   source.

                                                } else {

                                                   lookup in unicast RIB and

                                                   forward the Join towards
                                                   the source.
                                                }
                                          } else {
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Incorrect Destination"
                                          }
                                          }

7.2 Router receiving AMAP Auth-Ack for the Join-Ack message

    Endnode                               Router
    -------                               ------
    Send AMAP Auth-Ack ---------------->  Receive AMAP Auth-Ack for
    for the Join-Ack                      the Join-Ack message
    message
                                          if (error in message processing)
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Appropriate Message Error
                                                Code"

                                          if (error in cookie received)
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Incorrect Cookie Value"

                                          Lookup received (S, G) entry

                                          if (found) {
                                              Stop the Join-expire Timer

                                              Add the tunnel interface to
                                              outgoing list.

                                              if (PIM enabled &&
                                                  first interface) {
                                                   Send PIM Join message
                                               }
                                          } else {
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Unrecognised Route Entry
                                                 Pruned"
                                          }

7.3 Router receiving AMAP Prune message

    Endnode                               Router
    -------                               ------
    Send AMAP Prune   ------------------>  Receive AMAP Prune message
    message

Patel, Perlman, Farinacci, Shepherd, Eubanks                   [Page 14]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


                                          if (error in message processing)
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Appropriate Message Error
                                                Code"

                                          Lookup received (S, G) entry and
                                          tunnel interface in oif-list

                                          if (found) {
                                             Start the Prune-expire Timer
                                             for received interface

    Receive AMAP Prune-Ack <-------------    Send Prune-Ack message with
    message                                  the router cookie value

                                          } else {
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Unrecognised Route Entry
                                                 Pruned"
                                          }

7.4 Router receiving AMAP Auth-Ack message for the Prune-Ack message

    Endnode                               Router
    -------                               ------
    Send AMAP Auth-Ack ---------------->  Receive AMAP Auth-Ack for
    for the Prune-Ack                     the Prune-Ack message
    message
                                          if (error in message processing)
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="", Subtype=
                                                "Appropriate Message Error
                                                Code"

                                          if (error in cookie received)
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Incorrect Cookie Value"

                                          Lookup received (S, G) entry and
                                          tunnel interface in oif-list

                                          if (found) {
                                              Stop the Prune-expire Timer
                                              for a received interface

                                              Remove the tunnel interface to
                                              outgoing list.

                                              if (PIM enabled &&
                                                  last interface) {
                                                   Send PIM Prune message
                                                   Remove (S, G) entry
                                               }
                                          } else {
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Unrecognised Route Entry
                                                 Pruned"
                                          }

7.5 Hosts receiving AMAP Join-Ack or Prune-Ack messages


    Endnode                                     Router
    -------                                     ------
    Receive AMAP Join/Prune-Ack <--------    Send Join/Prune-Ack message with
    message                                  the router cookie value

Patel, Perlman, Farinacci, Shepherd, Eubanks                   [Page 15]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


    Send Auth-Ack message
    with Router's cookie value  --------->   Receive Auth-Ack messages
    received in Join/Prune message

7.6 Hosts receiving AMAP Query messages

    Endnode                                     Router
    -------                                     ------
                                             Re-schedule Query time

                                             schedule Join-expire Timer
                                             for a received interface

    Receive AMAP Query     <-------------    Send Query message
    message

    Send AMAP Join message
    for interested (S, G)   ------------->   Receive AMAP Join messages
    groups

7.7 Routers sending AMAP Prune messages

    Endnode                               Router
    -------                               ------
                                          Start the Prune-expire Timer
                                          for a tunnel interface

    Receive an       <------------------  Send an AMAP Prune message with
    AMAP Prune message                    the router cookie value

    if (error in message processing)
       Send Notification message with ->  Receive AMAP Notification message
       Type="Error", Subtype=             if (cookie value matches stored
       "Appropriate Message Error             cookie value) {
       Code"                                  Lookup received (S, G) entry and
                                              tunnel interface in oif-list

                                              if (found) {
                                                 Stop the Prune-expire Timer
                                                 for a received interface

                                                 Remove the tunnel interface to
                                                 outgoing list.

                                              }
                                          }
    Send AMAP Prune-Ack  ------------->   Receive Prune-Ack message with
    message                               the host cookie value

                                          Lookup received (S, G) entry and
                                          tunnel interface in oif-list

                                          if (found) {
                                              Stop the Prune-expire Timer
                                              for a received interface

                                              Remove the tunnel interface to
                                              outgoing list.

                                          } else {
    Receive AMAP          <-------------        Send Notification message with
    Notification message                        Type="Error", Subtype=
                                                "Unrecognised Route Entry
                                                 Pruned"
                                          }

Patel, Perlman, Farinacci, Shepherd, Eubanks                   [Page 16]


Internet Draft      draft-keyur-amap-00.txt                 October 2003


8. Tunnel Interfaces
   Because not all intermediate routers support native ip multicast,
   AMAP requires all the oifs on which it receives Host Join or Prune
   messages from receivers which are not directly connected to be created
   as tunnel interfaces. In practice, tunnels typically use either IP-IP
   [Perk96] or Generic Routing Encapsulation (GRE) [Han94a,Han94b],
   although, other encapsulation methods are acceptable.


9. Security Considerations

   AMAP does not change any multicast security issues. PIM is open to many
   types of resource overload. For instance, a node which transmits from
   many bogus source addresses will cause PIM routers to join to many (S, G)
   pairs, eventually exhausting the state. PIM routers must protect themselves
   by limiting the amount of state for multicast, so that a denial of
   service attack on multicast will not destroy unicast.

   With LAN-based IGMP join message, only nodes on the LAN can initiate
   a join message, so if the LAN is physically protected, and all
   routers along the path to the RP (or S in an (S, G) join) are trusted,
   it might be somewhat harder for a node to create a join state
   untraceably than it would with this tunnel proposal. With this
   tunnel proposal, the join message is sent over a multi-hop path.

   As stated in the document, a router is configured with a maximum
   number of tunnels it is willing to accept, so an attack to deplete
   its tunnel resources will only affect attempts to create tunnels,
   and not cause any other denial of service.

   Additionally, the router to whom tunnels will be created is likely
   to be the entry router at an ISP, and it can consider an entire customer
   network to be a LAN. If suspiciously large number of tunnels are
   being created from that customer network, then the router can start
   discriminating against join messages from that customer network,
   when resources are being depleted.

   Eventually, cryptographic authentication can be added between the
   joiner and the router, by having potential joiners obtain a key (or
   certificate) from the router before they are allowed to join, and
   having join messages cryptographically authenticated.


10. Acknowledgements

   We express our thanks to Alex Zinin, Lorenzo Vicisano, liming Wei,
   Tom Pusateri, and Nidhi Bhaskar for their review and comments on the
   earlier versions of the draft.


11. References

   [PIM-SM]  Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas,
             "Protocol Independent Multicast - Sparse Mode (PIM-SM):
             Protocol Specification (Revised)".

   [Han94a]  Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic
             Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and
             cisco Systems, October 1994.

   [Han94b]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
             Routing Encapsulation over IPv4 networks", RFC 1702,
             NetSmiths, Ltd., cisco Systems, October 1994.

   [Perk96]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
             October 1996.

Patel, Perlman, Farinacci, Shepherd, Eubanks                   [Page 17]

Internet Draft      draft-keyur-amap-00.txt                 October 2003


12. Author Information

   Keyur Patel
   Cisco Systems. Inc.
   email: keyupate@cisco.com

   Radia Perlman
   Sun Microsystems. Inc.
   email: Radia.Perlman@sun.com

   Dino Farinacci
   Procket Networks Inc.
   email: dino@procket.com

   Greg Shepherd
   Procket Networks Inc.
   email: shep@procket.com

   Marshall Eubanks
   Multicast Technologies Inc.
   email: tme@multicasttech.com