RFC1770 IPv4 Option for Sender Directed Multi-Destination Delivery

1770 IPv4 Option for Sender Directed Multi-Destination Delivery. C.Graff. March 1995. (Format: TXT=11606 bytes) (Status: INFORMATIONAL)

日本語訳
RFC一覧

参照

Network Working Group                                           C. Graff
Request for Comments: 1770                                 US Army CECOM
Category: Informational                                       March 1995


       IPv4 Option for Sender Directed Multi-Destination Delivery

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This memo defines an IPv4 option to provide a sender directed multi-
   destination delivery mechanism called Selective Directed Broadcast
   Mode (SDBM).  The SDBM provides unreliable UDP delivery to a set of
   IP addresses included in the option field of an IPv4 datagram.  Data
   reliability if required will be provided by the application layer.
   This approach was developed to support sender directed multi-
   destination delivery to sparsely populated groups with no additional
   control traffic.  This approach will find application in the
   extremely bandwidth constrained tactical military environment, as
   well as in some commercial applications requiring sender control of
   data delivery.

Background

   The Selective Directed Broadcast Mode (SDBM) is an integral part of
   the U.S. Army standard for tactical data communication networks as
   defined in MIL-STD-188-220() (Reference 1). The MIL-STD-188-220()
   defines a protocol architecture for the lower four layers of the
   ISO-OSI Reference model. The MIL-STD-188-220() is currently
   undergoing a reformatting to be consistent with other DoD standards
   that deal with IP networking. These efforts will provide tactical IP
   internetting of tactical Army broadcast radio networks, and will
   support fully IP compliant internetworking to other types of IP
   networks via commercial IP routers.  It is the goal of the U.S. Army
   to move toward a fully IP compliant internetwork architecture for all
   tactical battlefield data communications. The Army does, however,
   have a critical need for a reliable, sender directed multi-
   destination data transfer capability that is not currently supported
   by the existing or emerging internet standards. The SDBM IP option
   was developed to meet this need. The required data reliability will
   be provided by incorporating an acknowledgement strategy at the
   application layer. It is hoped that this IP option, providing multi-
   destination capability not currently provided by the current and



Graff                                                           [Page 1]

RFC 1770         Selective Directed Broadcast Protocol        March 1995


   emerging internet standards, will be embraced by the internet
   community and become an integal part of the IP family of protocols
   and be incorporated in commercial IP software products.

SDBM Format

   The SDBM provides the ability for an application to explicitly list a
   set of intended IP destinations. This capability will be implemented
   as an option in the IP layer, as shown in Figure 1. This option field
   is variable in length, up to a maximum of 40 octets due to the
   limitation of the HLEN field as specified in STD 5, RFC 791
   (Reference 2). Under this option 38 of the 40 octets would be used to
   contain the 2 octet control field and a maximum of 9 IP addresses.


       1            8           16                      31

       ***************************************************
       |            |            |                       |
       |            |            |                       |
       |  TYPE      |   LENGTH   |     IP ADDRESS 1      |
       |            |            |                       |
       |            |            |                       |
       |*************************************************|
       |                         |                       |
       |  IP ADDRESS 1(Cont)     |     IP ADDRESS 2      |
       |                         |                       |
       |                         |                       |
       |*************************************************|
       |                         |                       |
       |  IP ADDRESS 2(Cont)     |     ..........        |
       |                         |                       |
       |                         |                       |
       |*************************************************|
       |                         |                       |
       |                         |                       |
       |      ..........         |     IP ADDRESS N      |
       |                         |                       |
       |                         |                       |
       |*************************************************|
       |                         |                       |
       |    IP ADDRESS N(Cont)   |        UNUSED         |
       |                         |                       |
       |                         |                       |
       ***************************************************


                  Figure 1 IP Option Field Layout



Graff                                                           [Page 2]

RFC 1770         Selective Directed Broadcast Protocol        March 1995


   The TYPE field specifies the copy flag, class, and option number.
   The copy field indicates whether or not this option field is to be
   copied into each fragment if the IP datagram is fragmented. The class
   field and option number field are set to 0 and 21 respectively. The
   format of the TYPE field is shown at Figure 2.

          1                                                8
          **************************************************
          |      |           |                             |
          | COPY |   CLASS   |    OPTION NUMBER            |  =  149
          |      |           |                             |
          **************************************************

                   Figure 2 Type Field Layout

   Since the IP multi-address list shall always be copied to all IP
   headers during fragmentation, the COPY bit should be set to 1.

   Returning to Figure 1, the LENGTH octet indicates how many octets are
   in the option field. It is calculated as:

           LENGTH = 2 + 4*(number of IP addresses)

   The remaining octets contain the IP addresses of the specified
   destination hosts. Each IP address occupies 4 octets.

Transmission of SDBM datagrams

   The procedures for a source host, transit router, and destination
   router are provided below. When a source host has a message to send
   to multiple destination hosts, it shall,

   a. Group the destination host internet addresses by their network
      identifiers (Net IDs). If there are N distinct Net IDs, there will
      be at least N distinct directed broadcast packets. If there are
      more that 9 destination hosts on a single net, multiple directed
      broadcast datagrams must be sent to that net.

   b. For each Net ID, form the directed broadcast address as defined in
      STD 3, RFC 1122 (Reference 3) for that network. The directed
      broadcast address is used as the destination address in the IP
      datagram and the source address is the address of the host sending
      the message.

   c. Place the entire IP address for up to 9 destination hosts in the in
      the same net in the option field defined above. The total length of
      all IP options in a given datagram is limited to 40 octets as
      determined by the HLEN (Header Length) field which defines the



Graff                                                           [Page 3]

RFC 1770         Selective Directed Broadcast Protocol        March 1995


      number of 32 bit words in the header. If other options are to be
      included in addition to the SDBM option, the number of addresses in
      the option field must be reduced accordingly.

   d. The thusly formed datagram shall be transmitted and processed
      according to normal datagram handling procedures.

   When a IP SDBM datagram encounters a transit router (router not
   connected to the destination network), the datagram shall be
   processed in accordance with normal IP datagram handling procedures.
   When encountering the destination router (the destination network is
   directly attached to the router), the destination router shall
   perform a, b or c below:

   a. If the local subnet has a broadcast capability, broadcast to all
      hosts in the network and let the hosts perform address filtering.

   b. If the local subnet does not support broadcast, form a local subnet
      packet for each destination host in the SDBM datagram and transmit
      into the network.

   c. If the local subnet supports reliable layer 2 multi-address
      capability as provided by MIL-STD-188-220() networks, use a layer 2
      multi-address frame to deliver the datagram to addresses found in
      the IP option field.

Reception of SDBM datagrams

   In processing received SDBM datagrams, receiving hosts shall look
   inside the IP option field for their address. Processing shall
   continue only if the host's IP address is found inside this option
   field. Thus the source host has explicit control over which hosts
   will process its datagrams. Since SDBM uses a broadcast address in
   its destination field, the SDBM can only be used with UDP (Reference
   4) and not TCP (Reference 5) as the TCP supports only point-to-point
   connections and not point-to-multi-point.















Graff                                                           [Page 4]

RFC 1770         Selective Directed Broadcast Protocol        March 1995


Source for MIL-STD-188-220()

   The above mentioned MIL-STD-188-220() may be obtained by contacting

   US Army Communications Electronics Command
   AMSEL-RD-SE-AIN-E (ATTN: Mr. Ted Dzik)
   Fort Monmouth, NJ 07703

   Comm: (908) 532-1780
   Fax:  (908) 532-3398
   EMail: DZIK@ain3.monmouth.army.mil

Acknowledgements

   The author wishes to acknowledge the major contributions to this work
   made by Mr. Dave Macauley of ATT and Ms. Barbara Denny of SRI
   International.  Other contributions were made by members of the 188-
   220() committee.

References

   (1) "MIL-STD-188-220() For Task Force XXI, Interoperability Standard
       for Digital Message Transfer Device Subsystems, 23 December 1994.

   (2) Postel, J., "Internet Protocol - DARPA Internet Program Protocol
       Specification", STD 5, RFC 791, DARPA, September 1981.

   (3) Braden, R., Editor, "Requirements for Internet Hosts --
       Communication Layers" STD 3, RFC 1122, IETF, October 1989.

   (4) Postel, J., "User Datagram Protocol", STD 6, RFC 768,
       USC/Information Sciences Institute, August 1980.

   (5) Postel, J., "Transmission Control Protocol - DARPA Internet
       Program Protocol Specification", STD 7, RFC 793, September 1981.

Security Considerations

       Security issues are not discussed in this memo.












Graff                                                           [Page 5]

RFC 1770         Selective Directed Broadcast Protocol        March 1995


Author's Address

       US Army Communications Electronics Command
       AMSEL-RD-ST-LA-L ( ATTN: Charles Graff )
       Ft. Monmouth, NJ 07703

       Phone: (908) 544 3264
       Fax:   (908) 544 2150
       EMail: bud@fotlan5.fotlan.army.mil










































Graff                                                           [Page 6]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Firefoxでファイル名を指定して保存する方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る