tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2362

 
 
 

Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification

Part 3 of 3, p. 41 to 66
Prev RFC Part

 


prevText      Top       Page 41 
4 Packet Formats

   This section describes the details of the packet formats for PIM
   control messages.

   All PIM control messages have protocol number 103.

   Basically, PIM messages are either unicast (e.g.  Registers and
   Register-Stop), or multicast hop-by-hop to `ALL-PIM-ROUTERS' group
   `224.0.0.13' (e.g. Join/Prune, Asserts, etc.).

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Ver
              PIM Version number is 2.

        Type  Types for specific PIM messages.  PIM Types are:

           0 = Hello
           1 = Register
           2 = Register-Stop
           3 = Join/Prune
           4 = Bootstrap
           5 = Assert
           6 = Graft (used in PIM-DM only)
           7 = Graft-Ack (used in PIM-DM only)
           8 = Candidate-RP-Advertisement

        Reserved
              set to zero. Ignored upon receipt.

        Checksum
             The checksum is the 16-bit one's complement of the one's
             complement sum of the entire PIM message, (excluding the
             data portion in the Register message).  For computing the
             checksum, the checksum field is zeroed.

Top       Page 42 
4.1 Encoded Source and Group Address formats

1    Encoded-Unicast-address: Takes the following format:

  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 address family of the `Unicast Address' field  of
           this address.

          Here is the address family numbers assigned by IANA:

 Number    Description
 --------  ---------------------------------------------------------
      0    Reserved
      1    IP (IP version 4)
      2    IP6 (IP version 6)
      3    NSAP
      4    HDLC (8-bit multidrop)
      5    BBN 1822
      6    802 (includes all 802 media plus Ethernet "canonical format")
      7    E.163
      8    E.164 (SMDS, Frame Relay, ATM)
      9    F.69 (Telex)
     10    X.121 (X.25, Frame Relay)
     11    IPX
     12    Appletalk
     13    Decnet IV
     14    Banyan Vines
     15    E.164 with NSAP format subaddress

     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.

Top       Page 43 
2    Encoded-Group-Address: Takes the following format:

  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 |   Reserved    |  Mask Len     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Group multicast Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Addr Family
           described above.

     Encoding Type
           described above.

     Reserved
           Transmitted as zero. Ignored upon receipt.

     Mask Len
          The Mask length is 8 bits. The value is the number of
          contiguous bits left justified used as a mask which
          describes the address. It is less than or equal to the
          address length in bits for the given Address Family
          and Encoding Type. If the message is sent for a single
          group then the Mask length must equal the address
          length in bits for the given Address Family and
          Encoding Type.  (e.g. 32 for IPv4 native encoding and
          128 for IPv6 native encoding).

     Group multicast Address
           contains the group address.

3    Encoded-Source-Address: Takes the following format:

  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 | Rsrvd   |S|W|R|  Mask Len     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Source Address                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Addr Family
           described above.

     Encoding Type
           described above.

Top       Page 44 
     Reserved
           Transmitted as zero, ignored on receipt.

     S,W,R See Section 4.5 for details.

     Mask Length
          Mask length is 8 bits. The value is the number of
          contiguous bits left justified used as a mask which
          describes the address. The mask length must be less
          than or equal to the address length in bits for the
          given Address Family and Encoding Type. If the message
          is sent for a single group then the Mask length must
          equal the address length in bits for the given Address
          Family and Encoding Type. In version 2 of PIM, it is
          strongly recommended that this field be set to 32 for
          IPv4 native encoding.

     Source Address
           The source address.

4.2 Hello Message

   It is sent periodically by routers on all interfaces.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       OptionType              |         OptionLength          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          OptionValue                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       OptionType              |         OptionLength          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          OptionValue                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++


        PIM Version, Type, Reserved, Checksum
              Described above.

Top       Page 45 
        OptionType
              The type of the option given in the following  OptionValue
             field.

        OptionLength
              The length of the OptionValue field in bytes.

        OptionValue
              A variable length field, carrying the value of the option.

        The Option fields may contain the following values:

     *    OptionType = 1; OptionLength = 2; OptionValue = Holdtime;
          where Holdtime is the amount of time a receiver must keep the
          neighbor reachable, in seconds. If the Holdtime is set to
          `0xffff', the receiver of this message never times out the
          neighbor. This may be used with ISDN lines, to avoid keeping
          the link up with periodic Hello messages.  Furthermore, if the
          Holdtime is set to `0', the information is timed out
          immediately.

     *    OptionType 2 to 16: reserved

     *    The rest of the OptionTypes are defined in another
          document.

   In general, options may be ignored; but a router must not ignore the

4.3 Register Message

   A Register message is sent by the DR or a PMBR to the RP when a
   multicast packet needs to be transmitted on the RP-tree. Source
   address is set to the address of the DR, destination address is to
   the RP's 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |B|N|                       Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
                          Multicast data packet
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top       Page 46 
        PIM Version, Type, Reserved, Checksum
              Described above. Note that the checksum for Registers
             is done only on the PIM header, excluding the data packet
             portion.

        B     The Border bit. If the router is a DR for a source that it
             is directly connected to, it sets the B bit to 0. If the
             router is a PMBR for a source in a directly connected
             cloud, it sets the B bit to 1.

        N     The Null-Register bit. Set to 1 by a DR that is probing
             the RP before expiring its local Register-Suppression
             timer. Set to 0 otherwise.

        Multicast data packet
              The original packet sent by the source.

        For (S,G) null Registers, the Multicast data packet portion
        contains only a dummy header with S as the source address, G as
        the destination address, and a data length of zero.

4.4 Register-Stop Message

   A Register-Stop is unicast from the RP to the sender of the Register
   message.  Source address is the address to which the register was
   addressed.  Destination address is the source address of the register
   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Encoded-Group Address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Encoded-Unicast-Source Address             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Encoded-Group Address
              Format described above. Note that for Register-Stops the
             Mask Len field contains full address length * 8 (e.g. 32
             for IPv4 native encoding), if the message is sent for a
             single group.

Top       Page 47 
        Encoded-Unicast-Source Address
              host address of source from multicast data packet in
             register. The format for this address is given in the
             Encoded-Unicast-Address in 4.1. A special wild card value
             (0's), can be used to indicate any source.

4.5 Join/Prune Message

   A Join/Prune message is sent by routers towards upstream sources and
   RPs.  Joins are sent to build shared trees (RP trees) or source trees
   (SPT). Prunes are sent to prune source trees when members leave
   groups as well as sources that do not use the shared tree.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Encoded-Unicast-Upstream Neighbor Address         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Reserved     | Num groups    |          Holdtime             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Encoded-Multicast Group Address-1                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Number of Joined  Sources   |   Number of Pruned Sources    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Joined Source Address-1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             .                                 |
    |                             .                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Joined Source Address-n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Pruned Source Address-1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             .                                 |
    |                             .                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Pruned Source Address-n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           .                                   |
    |                           .                                   |
    |                           .                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Encoded-Multicast Group Address-n              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Number of Joined  Sources   |   Number of Pruned Sources    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top       Page 48 
    |               Encoded-Joined Source Address-1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             .                                 |
    |                             .                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Joined Source Address-n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Pruned Source Address-1                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             .                                 |
    |                             .                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Encoded-Pruned Source Address-n                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Encoded-Unicast Upstream Neighbor Address
              The address of the RPF or upstream neighbor.  The format
             for this address is given in the Encoded-Unicast-Address in
             4.1. .IP "Reserved"
              Transmitted as zero, ignored on receipt.

        Holdtime
              The amount of time a receiver must keep the Join/Prune
             state alive, in seconds.  If the Holdtime is set to
             `0xffff', the receiver of this message never times out the
             oif. This may be used with ISDN lines, to avoid keeping the
             link up with periodical Join/Prune messages.  Furthermore,
             if the Holdtime is set to `0', the information is timed out
             immediately.

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

        Encoded-Multicast group address
              For format description see Section
              4.1. A wild card group in the (*,*,RP) join is represented
             by a 224.0.0.0 in the group address field and `4' in the
             mask length field. A (*,*,RP) join also has the WC-bit and
             the RPT-bit set.

        Number of Joined Sources
              Number of join source addresses listed for a given group.

Top       Page 49 
        Join Source Address-1 .. n
              This list contains the sources that the sending router
             will forward multicast datagrams for if received on the
             interface this message is sent on.

             See format section 4.1. The fields explanation for the
             Encoded-Source-Address format follows:

             Reserved
                   Described above.

             S     The Sparse bit is a 1 bit value, set to 1 for PIM-SM.
                  It is used for PIM v.1 compatibility.

             W     The WC bit is a 1 bit value. If 1, the join or  prune
                  applies to the (*,G) or (*,*,RP) entry. If 0, the join
                  or prune applies to the (S,G) entry where S is Source
                  Address.  Joins and prunes sent towards the RP must
                  have this bit set.

             R     The RPT-bit is a 1 bit value. If 1, the information
                  about (S,G) is sent towards the RP.  If 0, the
                  information must be sent toward S, where S is the
                  Source Address.

             Mask Length, Source Address
                   Described above.

             Represented in the form of
             <  WC-bit  ><  RPT-bit  ><Mask length >< Source address>:

             A source address could be a host IPv4 native encoding
             address :

              < 0 >< 0 >< 32 >< 192.1.1.17 >

             A source address could be the RP's IP address :

              < 1 >< 1 >< 32 >< 131.108.13.111 >

             A source address could be a subnet address to prune from
             the RP-tree :

              < 0 >< 1 >< 28 >< 192.1.1.16 >

             A source address could be a general aggregate :

              < 0 >< 0 >< 16 >< 192.1.0.0 >

Top       Page 50 
        Number of Pruned Sources
              Number of prune source addresses listed for a group.

        Prune Source Address-1 .. n
              This list contains the sources that the sending router
             does not want to forward multicast datagrams for when
             received on the interface this message is sent on.  If the
             Join/Prune message boundary exceeds the maximum packet
             size, then the join and prune lists for the same group must
             be included in the same packet.

4.6 Bootstrap Message

   The Bootstrap messages are multicast to `ALL-PIM-ROUTERS' group, out
   all interfaces having PIM neighbors (excluding the one over which the
   message was received).  Bootstrap messages are sent with TTL value of
   1. Bootstrap messages originate at the BSR, and are forwarded by
   intermediate routers.

   Bootstrap message is divided up into `semantic fragments', if the
   original message exceeds the maximum packet size boundaries.

   The semantics of a single `fragment' is given 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Fragment Tag          | Hash Mask len | BSR-priority  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-BSR-Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-1               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RP-Count-1    | Frag RP-Cnt-1 |         Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-1                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP1-Holdtime         | RP1-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-2                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP2-Holdtime         | RP2-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top       Page 51 
    |                 Encoded-Unicast-RP-Address-m                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RPm-Holdtime         | RPm-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-2               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RP-Count-n    | Frag RP-Cnt-n |          Reserved             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-1                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP1-Holdtime         | RP1-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-2                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RP2-Holdtime         | RP2-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address-m                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          RPm-Holdtime         | RPm-Priority  |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Fragment Tag
              A randomly generated number, acts to distinguish the
             fragments belonging to different Bootstrap messages;
             fragments belonging to same Bootstrap message carry the
             same `Fragment Tag'.

        Hash Mask len
              The length (in bits) of the mask to use in the hash
             function. For IPv4 we recommend a value of 30. For IPv6 we
             recommend a value of 126.

        BSR-priority
              Contains the BSR priority value of the included BSR.  This
             field is considered as a high order byte when comparing BSR
             addresses.

Top       Page 52 
        Encoded-Unicast-BSR-Address
              The address of the bootstrap router for the domain.  The
             format for this address is given in the Encoded-Unicast-
             Address in 4.1. .IP "Encoded-Group Address-1..n"
              The group prefix (address and mask) with which the
             Candidate RPs are associated. Format previously described.

        RP-Count-1..n
              The number of Candidate RP addresses included in the whole
             Bootstrap message for the corresponding group prefix. A
             router does not replace its old RP-Set for a given group
             prefix until/unless it receives `RP-Count' addresses for
             that prefix; the addresses could be carried over several
             fragments.  If only part of the RP-Set for a given group
             prefix was received, the router discards it, without
             updating that specific group prefix's RP-Set.

        Frag RP-Cnt-1..m
              The number of Candidate RP addresses included in this
             fragment of the Bootstrap message, for the corresponding
             group prefix. The `Frag RP-Cnt' field facilitates parsing
             of the RP-Set for a given group prefix, when carried over
             more than one fragment.

        Encoded-Unicast-RP-address-1..m
              The address of the Candidate RPs, for the corresponding
             group prefix.  The format for this address is given in the
             Encoded-Unicast-Address in 4.1. .IP "RP1..m-Holdtime"
              The Holdtime for the corresponding RP.  This field is
             copied from the `Holdtime' field of the associated RP
             stored at the BSR.

        RP1..m-Priority
              The `Priority' of the corresponding RP and Encoded-Group
             Address.  This field is copied from the `Priority' field
             stored at the BSR when receiving a Candidate-RP-
             Advertisement.  The highest priority is `0' (i.e. the lower
             the value of the `Priority' field, the higher).  Note that
             the priority is per RP per Encoded-Group Address.

4.7 Assert Message

   The Assert message is sent when a multicast data packet is received
   on an outgoing interface corresponding to the (S,G) or (*,G)
   associated with the source.

Top       Page 53 
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Encoded-Group Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Encoded-Unicast-Source Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|                        Metric Preference                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Metric                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Encoded-Group Address
              The group address to which the data packet was addressed,
             and which triggered the Assert.  Format previously
             described.

        Encoded-Unicast-Source Address
              Source address from multicast datagram that triggered the
             Assert packet to be sent. The format for this address is
             given in the Encoded-Unicast-Address in 4.1. .IP "R"
              RPT-bit is a 1 bit value. If the multicast datagram that
             triggered the Assert packet is routed down the RP tree,
             then the RPT-bit is 1; if the multicast datagram is routed
             down the SPT, it is 0.

        Metric Preference
              Preference value assigned to the unicast routing protocol
             that provided the route to Host address.

        Metric The unicast routing table metric. The metric is in units
             applicable to the unicast routing protocol used.

4.8 Graft Message

   Used in dense-mode. Refer to PIM dense mode specification.

4.9 Graft-Ack Message

   Used in dense-mode. Refer to PIM dense mode specification.

Top       Page 54 
4.10 Candidate-RP-Advertisement

   Candidate-RP-Advertisements are periodically unicast from the C-RPs
   to the BSR.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PIM Ver| Type  | Reserved      |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Prefix-Cnt    |   Priority    |             Holdtime          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Encoded-Unicast-RP-Address                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-1               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               .                               |
    |                               .                               |
    |                               .                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Encoded-Group Address-n               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        PIM Version, Type, Reserved, Checksum
              Described above.

        Prefix-Cnt
              The number of encoded group addresses included in the
             message; indicating the group prefixes for which the C-RP
             is advertising. A Prefix-Cnt of `0' implies a prefix of
             224.0.0.0 with mask length of 4; i.e. all multicast groups.
             If the C-RP is not configured with Group-prefix
             information, the C-RP puts a default value of `0' in this
             field.

        Priority
              The `Priority' of the included RP, for the corresponding
             Encoded-Group Address (if any).  highest priority is `0'
             (i.e. the lower the value of the `Priority' field, the
             higher the priority). This field is stored at the BSR upon
             receipt along with the RP address and corresponding
             Encoded-Group Address.

        Holdtime
              The amount of time the advertisement is valid. This field
             allows advertisements to be aged out.

Top       Page 55 
        Encoded-Unicast-RP-Address
              The address of the interface to advertise as a Candidate
             RP.  The format for this address is given in the Encoded-
             Unicast-Address in 4.1. .IP "Encoded-Group Address-1..n"
              The group prefixes for which the C-RP is advertising.
             Format previously described.

5 Acknowledgments

   Tony Ballardie, Scott Brim, Jon Crowcroft, Bill Fenner, Paul Francis,
   Joel Halpern, Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia
   Zhang and Girish Chandranmenon provided detailed comments on previous
   drafts. The authors of CBT [8] and membership of the IDMR WG provided
   many of the motivating ideas for this work and useful feedback on
   design details.

   This work was supported by the National Science Foundation, ARPA,
   cisco Systems and Sun Microsystems.

Top       Page 56 
6 Appendices

6.1 Appendix I: Major Changes and Updates to the Spec

   This appendix populates the major changes in the specification
   document as compared to `draft-ietf-idmr-pim-spec-01.ps,txt'.

   bsubsection*Major Changes

   List of changes since March '96 IETF:

     1. (*,*,RP) Joins state and data forwarding check; replaces (*,G-
     Prefix) Joins state for interoperability. (*,G) negative cache
     introduced for the (*,*,RP) state supporting mechanisms.

     2. Semantic fragmentation for the Bootstrap message.

     3. Refinement of Assert details.

     4. Addition and refinement of Join/Prune suppression and Register
     suppression (introduction of null Registers).

     5. Editorial changes and clarifications to the timers section.

     6. Addition of Appendix II (BSR Election and RP-Set Distribution),
     and Appendix III (Glossary of Terms).

     7. Addition of table of contents.

   List of changes incurred since version 1 of the spec.:

     1. Proposal and refinement of bootstrap router (BSR) election
     mechanisms

     2. Introduction of hash functions for Group to RP mapping

     3. New RP-liveness indication mechanisms based upon the the
     Bootstrap Router (BSR) and the Bootstrap messages.

     4. Removal of reachability messages, RP reports and multiple RPs
     per group.

   *Packet Format Changes

     Packet Format incurred updates to accommodate different address
     lengths, and address aggregation.

Top       Page 57 
     1 The `Addr Family' and `Encoding Type' fields were added to the
     packet formats.

     2 The Encoded source and group address formats were introduced,
     with the use of a `Mask length' field to allow aggregation, section
     4.1.

     3 Packet formats are no longer IGMP messages; rather PIM messages.

   PIM message types and formats were also modified:

   [Note: most changes were made to the May  95  version,  unless
   otherwise specified].

     1    Obsolete messages:

         Register-Ack [Feb. 96]

         Poll and Poll Response [Feb. 96]

         RP-Reachability [Feb. 96]

         RPlist-Mapping [Feb. 96]


     2     New messages:

         Candidate-RP-Advertisement [change made in  October  95]
         RP-Set [Feb. 96]

     3       Modified messages:

         Join/Prune [Feb. 96]
         Register [Feb. 96]
         Register-Stop [Feb.  96]
         Hello (addition of OptionTypes) [Aug 96]

     4        Renamed messages:

          Query messages are renamed as Hello messages [Aug. 96]
          RP-Set  messages are renamed as Bootstrap messages [Aug. 96]

Top       Page 58 
6.2 Appendix II: BSR Election and RP-Set Distribution

   For simplicity, the bootstrap message is used in both the BSR
   election and the RP-Set distribution mechanisms.  These mechanisms
   are described by the following state machine, illustrated in figure
   4.  The protocol transitions for a Candidate-BSR are given  in state
   diagram (a).  For routers not configured as Candidate-BSRs, the
   protocol transitions are given in state diagram (b).

     [Figures are present only in the postscript version] Fig. 4 State
           Diagram for the BSR election and RP-Set distribution

   Each PIM router keeps a bootstrap-timer, initialized to [Bootstrap-
   Timeout], in addition to a local BSR field `LclBSR' (initialized to a
   local address if Candidate-BSR, or to 0 otherwise), and a local RP-
   Set `LclRP-Set' (initially empty). The main stimuli to the state
   machine are timer events and arrival of bootstrap messages:

        bsubsection*Initial States and Timer Events

        1

        2    If the router is a Candidate-BSR:

             1

             2 The router operates initially in the `CandBSR' state,
               where it does not originate any bootstrap messages.

             3 If the bootstrap-timer expires, and the current state
               is `CandBSR', the router originates a bootstrap
               message carrying the local RP-Set and its own BSR
               priority and address, restarts the bootstrap-timer at
               [Bootstrap-Period] seconds, and transits into the
               `ElectedBSR' state. Note that the actual sending of
               the bootstrap message may be delayed by a random value
               to reduce transient control overhead. To obtain best
               results, the random value is set such that the
               preferred BSR is the first to originate a bootstrap
               message. We propose the following as an efficient
               implementation of the random value delay (in seconds):

         Delay = 5 + 2 * log_2(1 + bestPriority - myPriority) + AddrDelay

               where myPriority is the Candidate-BSR's
               configured priority, and bestPriority equals:

                 bestPriority = Max(storedPriority, myPriority) ]

Top       Page 59 
               and AddrDelay is given by the following:


               1 if ( bestPriority equals myPriority) then
               [AddrDelay = log_2(bestAddr - myAddr) / 16, ]

               2 else [AddrDelay = 2 - (myAddr / 2^31) ]

               where myAddr is the Candidate-BSR's address, and
               bestAddr is the stored BSR's address.


             4 If the bootstrap-timer expires, and the current state
               is `ElectedBSR', the router originates a bootstrap
               message, and restarts the RP-Set timer at [Bootstrap-
               Period]. No state transition is incurred.

               This way, the elected BSR originates periodic
               bootstrap messages every [Bootstrap-Period].

        3 If a router is not a Candidate-BSR:


             1

             2 The router operates initially in the `AxptAny' state.
               In such state, a router accepts the first bootstrap
               message from the The Reverse Path Forwarding (RPF)
               neighbor toward the included BSR. The RPF neighbor in
               this case is the next hop router en route to the
               included BSR.

             3 If the bootstrap-timer expires, and the current state
               is `AxptPref'-- where the router accepts only
               preferred bootstrap messages (those that carry BSR-
               priority and address higher than, or equal to,
               `LclBSR') from the RPF neighbor toward the included
               BSR-- the router transits into the `AxptAny' state.

               In this case, if an elected BSR becomes unreachable,
               the routers start accepting bootstrap messages from
               another Candidate-BSR after the bootstrap-timer
               expires.  All PIM routers within a domain converge on
               the preferred reachable Candidate-BSR.

Top       Page 60 
        Receiving Bootstrap Message:

        To avoid loops, an RPF check is performed on the included BSR
        address.  Upon receiving a bootstrap message from the RPF
        neighbor toward the included BSR, the following actions are
        taken:

        1 If the router is not a Candidate-BSR:

             1 If the current state is `AxptAny', the router accepts
               the bootstrap message, and transits into the
               `AxptPref' state.

             2 If the current state is `AxptPref', and the bootstrap
               message is preferred, the message is accepted. No
               state transition is incurred.

        2 If the router is a Candidate-BSR, and the bootstrap message
          is preferred, the message is accepted. Further, if this
          happens when the current state is `Elected BSR', the router
          transits into the `CandBSR' state.

        When a bootstrap message is accepted, the router restarts the
        bootstrap-timer at [Bootstrap-Timeout], stores the received BSR
        priority and address in `LclBSR', and the received RP-Set in
        `LclRP-Set', and forwards the bootstrap message out all
        interfaces except the receiving interface.

        If a bootstrap message is rejected, no state transitions are
        triggered.

Top       Page 61 
6.3 Appendix III: Glossary of Terms

   Following is an alphabetized list of terms and definitions used
   throughout this specification.

     *    { Bootstrap router (BSR)}. A BSR is a dynamically elected
          router within a PIM domain. It is responsible for constructing
          the RP-Set and originating Bootstrap messages.

     *    { Candidate-BSR (C-BSR)}. A C-BSR is a router configured to
          participate in the BSR election and act as BSRs if elected.

     *    { Candidate RP (C-RP)}. A C-RP is a router configured to
          send periodic Candidate-RP-Advertisement messages to the BSR,
          and act as an RP when it receives Join/Prune or Register
          messages for the advertised group prefix.

     *    { Designated Router (DR)}. The DR sets up multicast route
          entries and sends corresponding Join/Prune and Register
          messages on behalf of directly-connected receivers and
          sources, respectively.  The DR may or may not be the same
          router as the IGMP Querier. The DR may or may not be the
          long-term, last-hop router for the group; a router on the LAN
          that has a lower metric route to the data source, or to the
          group's RP, may take over the role of sending Join/Prune
          messages.

     *    { Incoming interface (iif)}. The iif of a multicast route
          entry indicates the interface from which multicast data
          packets are accepted for forwarding. The iif is initialized
          when the entry is created.

     *     Join list. The Join list is one of two lists of addresses
          that is included in a Join/Prune message; each address refers
          to a source or RP. It indicates those sources or RPs to which
          downstream receiver(s) wish to join.

     *    { Last-hop router}. The last-hop router is the last router
          to receive multicast data packets before they are delivered to
          directly-connected member hosts. In general the last-hop
          router is the DR for the LAN.  However, under various
          conditions described in this document a parallel router
          connected to the same LAN may take over as the last-hop router
          in place of the DR.

     *    { Outgoing interface (oif) list}.  Each multicast route
          entry has an oif list containing the outgoing interfaces to
          which multicast packets should be forwarded.

Top       Page 62 
     *     Prune List. The Prune list is the second list of addresses
          that is included in a Join/Prune message. It indicates those
          sources or RPs from which downstream receiver(s) wish to
          prune.

     *    { PIM Multicast Border Router (PMBR)}. A PMBR connects a
          PIM domain to other multicast routing domain(s).

     *    { Rendezvous Point (RP)}.  Each multicast group has a
          shared-tree via which receivers hear of new sources and new
          receivers hear of all sources. The RP is the root of this
          per-group shared tree, called the RP-Tree.

     *    { RP-Set}. The RP-Set is a set of RP addresses constructed
          by the BSR based on Candidate-RP advertisements received.  The
          RP-Set information is distributed to all PIM routers in the
          BSR's PIM domain.

     *    { Reverse Path Forwarding (RPF)}. RPF is used to select the
          appropriate incoming interface for a multicast route entry .
          The RPF neighbor for an address X is the the next-hop router
          used to forward packets toward X. The RPF interface is the
          interface to that RPF neighbor. In the common case this is the
          next hop used by the unicast routing protocol for sending
          unicast packets toward X. For example, in cases where unicast
          and multicast routes are not congruent, it can be different.

     *    { Route entry.} A multicast route entry is state maintained
          in a router along the distribution tree and is created, and
          updated based on incoming control messages. The route entry
          may be different from the forwarding entry; the latter is used
          to forward data packets in real time.  Typically a forwarding
          entry is not created until data packets arrive, the forwarding
          entry's iif and oif list are copied from the route entry, and
          the forwarding entry may be flushed and recreated at will.

     *    { Shortest path tree (SPT)}.  The SPT is the multicast
          distribution tree created by the merger of all of the shortest
          paths that connect receivers to the source (as determined by
          unicast routing).

     *    { Sparse Mode (SM)}. SM is one mode of operation of a
          multicast protocol.  PIM SM uses explicit Join/Prune messages
          and Rendezvous points in place of Dense Mode PIM's and DVMRP's
          broadcast and prune mechanism.

Top       Page 63 
     *    { Wildcard (WC) multicast route entry}. Wildcard multicast
          route entries are those entries that may be used to forward
          packets for any source sending to the specified group.
          Wildcard bots in the join list of a Join/Prune message
          represent either a (*,G) or (*,*,RP) join; in the prune list
          they represent a (*,G) prune.

     *    { (S,G) route entry}.  (S,G) is a source-specific route
          entry.  It may be created in response to data packets,
          Join/Prune messages, or Asserts. The (S,G) state in routers
          creates a source-rooted, shortest path (or reverse shortest
          path) distribution tree. (S,G)RPT bit entries are source-
          specific entries on the shared RP-Tree; these entries are used
          to prune particular sources off of the shared tree.

     *    { (*,G) route entry}. Group members join the shared RP-Tree
          for a particular group. This tree is represented by (*,G)
          multicast route entries along the shortest path branches
          between the RP and the group members.

     *    { (*,*,RP) route entry}. (*,*,RP) refers to any source and
          any multicast group that maps to the RP included in the entry.
          The routers along the shortest path branches between a
          domain's RP(s) and its PMBRs keep (*,*,RP) state and use it to
          determine how to deliver packets toward the PMBRs if data
          packets arrive for which there is not a longer match.  The
          wildcard group in the (*,*,RP) route entry is represented by a
          group address of 224.0.0.0 and a mask length of 4 bits.

References

   1. Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C.,
   Wei, L., Sharma, P., and A. Helmy, "Protocol Independent Multicast
   (pim): Motivation and Architecture", Work in Progress.

   2. S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L.
   Wei.  The pim architecture for wide-area multicast routing.  ACM
   Transactions on Networks, April 1996.

   3. Estrin, D., Farinacci, D., Jacobson, V., Liu, C., Wei, L., Sharma,
   P., and A. Helmy, "Protocol Independent Multicast-dense Mode (pim-
   dm): Protocol Specification", Work in Progress.

   4. Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
   1112, August 1989.

   5. Fenner, W., "Internet Group Management Protocol, Version 2", RFC
   2236, November 1997.

Top       Page 64 
   6. Atkinson, R., "Security Architecture for the Internet Protocol",
   RFC 1825, August 1995.

   7. Mark R. Nelson.  File verification using CRC.  Dr.  Dobb's
   Journal, May 1992.

   8. A.J. Ballardie, P.F. Francis, and J.Crowcroft. Core based trees.
   In Proceedings of the ACM SIGCOMM, San Francisco, 1993.

Authors' Addresses

   NOTE: The author list has been reordered to reflect the involvement
   in detailed editorial work on this specification document.  The first
   four authors are the primary editors and are listed alphabetically.
   The rest of the authors, also listed alphabetically, participated in
   all aspects of the architectural and detailed design but managed to
   get away without hacking the latex!

   Deborah Estrin
   Computer Science Dept/ISI
   University of Southern Calif.
   Los Angeles, CA 90089

   EMail: estrin@usc.edu


   Dino Farinacci
   Cisco Systems Inc.
   170 West Tasman Drive,
   San Jose, CA 95134

   EMail: dino@cisco.com


   Ahmed Helmy
   Computer Science Dept.
   University of Southern Calif.
   Los Angeles, CA 90089

   EMail: ahelmy@catarina.usc.edu


   David Thaler
   EECS Department
   University of Michigan
   Ann Arbor, MI 48109

   EMail: thalerd@eecs.umich.edu

Top       Page 65 
   Stephen Deering
   Xerox PARC
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   EMail: deering@parc.xerox.com

   Mark Handley
   Department of Computer Science
   University College London
   Gower Street
   London, WC1E 6BT
   UK

   EMail: m.handley@cs.ucl.ac.uk


   Van Jacobson
   Lawrence Berkeley Laboratory
   1 Cyclotron Road
   Berkeley, CA 94720

   EMail: van@ee.lbl.gov


   Ching-gung  Liu
   Computer Science Dept.
   University of Southern Calif.
   Los Angeles, CA 90089

   EMail: charley@catarina.usc.edu


   Puneet Sharma
   Computer Science Dept.
   University of Southern Calif.
   Los Angeles, CA 90089

   EMail: puneet@catarina.usc.edu


   Liming Wei
   Cisco Systems Inc.
   170 West Tasman Drive,
   San Jose, CA 95134

   EMail: lwei@cisco.com

Top       Page 66 
Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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 assigns.

   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.