home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1770 < prev    next >
Text File  |  1995-03-21  |  12KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           C. Graff
  8. Request for Comments: 1770                                 US Army CECOM
  9. Category: Informational                                       March 1995
  10.  
  11.  
  12.        IPv4 Option for Sender Directed Multi-Destination Delivery
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This memo defines an IPv4 option to provide a sender directed multi-
  23.    destination delivery mechanism called Selective Directed Broadcast
  24.    Mode (SDBM).  The SDBM provides unreliable UDP delivery to a set of
  25.    IP addresses included in the option field of an IPv4 datagram.  Data
  26.    reliability if required will be provided by the application layer.
  27.    This approach was developed to support sender directed multi-
  28.    destination delivery to sparsely populated groups with no additional
  29.    control traffic.  This approach will find application in the
  30.    extremely bandwidth constrained tactical military environment, as
  31.    well as in some commercial applications requiring sender control of
  32.    data delivery.
  33.  
  34. Background
  35.  
  36.    The Selective Directed Broadcast Mode (SDBM) is an integral part of
  37.    the U.S. Army standard for tactical data communication networks as
  38.    defined in MIL-STD-188-220() (Reference 1). The MIL-STD-188-220()
  39.    defines a protocol architecture for the lower four layers of the
  40.    ISO-OSI Reference model. The MIL-STD-188-220() is currently
  41.    undergoing a reformatting to be consistent with other DoD standards
  42.    that deal with IP networking. These efforts will provide tactical IP
  43.    internetting of tactical Army broadcast radio networks, and will
  44.    support fully IP compliant internetworking to other types of IP
  45.    networks via commercial IP routers.  It is the goal of the U.S. Army
  46.    to move toward a fully IP compliant internetwork architecture for all
  47.    tactical battlefield data communications. The Army does, however,
  48.    have a critical need for a reliable, sender directed multi-
  49.    destination data transfer capability that is not currently supported
  50.    by the existing or emerging internet standards. The SDBM IP option
  51.    was developed to meet this need. The required data reliability will
  52.    be provided by incorporating an acknowledgement strategy at the
  53.    application layer. It is hoped that this IP option, providing multi-
  54.    destination capability not currently provided by the current and
  55.  
  56.  
  57.  
  58. Graff                                                           [Page 1]
  59.  
  60. RFC 1770         Selective Directed Broadcast Protocol        March 1995
  61.  
  62.  
  63.    emerging internet standards, will be embraced by the internet
  64.    community and become an integal part of the IP family of protocols
  65.    and be incorporated in commercial IP software products.
  66.  
  67. SDBM Format
  68.  
  69.    The SDBM provides the ability for an application to explicitly list a
  70.    set of intended IP destinations. This capability will be implemented
  71.    as an option in the IP layer, as shown in Figure 1. This option field
  72.    is variable in length, up to a maximum of 40 octets due to the
  73.    limitation of the HLEN field as specified in STD 5, RFC 791
  74.    (Reference 2). Under this option 38 of the 40 octets would be used to
  75.    contain the 2 octet control field and a maximum of 9 IP addresses.
  76.  
  77.  
  78.        1            8           16                      31
  79.  
  80.        ***************************************************
  81.        |            |            |                       |
  82.        |            |            |                       |
  83.        |  TYPE      |   LENGTH   |     IP ADDRESS 1      |
  84.        |            |            |                       |
  85.        |            |            |                       |
  86.        |*************************************************|
  87.        |                         |                       |
  88.        |  IP ADDRESS 1(Cont)     |     IP ADDRESS 2      |
  89.        |                         |                       |
  90.        |                         |                       |
  91.        |*************************************************|
  92.        |                         |                       |
  93.        |  IP ADDRESS 2(Cont)     |     ..........        |
  94.        |                         |                       |
  95.        |                         |                       |
  96.        |*************************************************|
  97.        |                         |                       |
  98.        |                         |                       |
  99.        |      ..........         |     IP ADDRESS N      |
  100.        |                         |                       |
  101.        |                         |                       |
  102.        |*************************************************|
  103.        |                         |                       |
  104.        |    IP ADDRESS N(Cont)   |        UNUSED         |
  105.        |                         |                       |
  106.        |                         |                       |
  107.        ***************************************************
  108.  
  109.  
  110.                   Figure 1 IP Option Field Layout
  111.  
  112.  
  113.  
  114. Graff                                                           [Page 2]
  115.  
  116. RFC 1770         Selective Directed Broadcast Protocol        March 1995
  117.  
  118.  
  119.    The TYPE field specifies the copy flag, class, and option number.
  120.    The copy field indicates whether or not this option field is to be
  121.    copied into each fragment if the IP datagram is fragmented. The class
  122.    field and option number field are set to 0 and 21 respectively. The
  123.    format of the TYPE field is shown at Figure 2.
  124.  
  125.           1                                                8
  126.           **************************************************
  127.           |      |           |                             |
  128.           | COPY |   CLASS   |    OPTION NUMBER            |  =  149
  129.           |      |           |                             |
  130.           **************************************************
  131.  
  132.                    Figure 2 Type Field Layout
  133.  
  134.    Since the IP multi-address list shall always be copied to all IP
  135.    headers during fragmentation, the COPY bit should be set to 1.
  136.  
  137.    Returning to Figure 1, the LENGTH octet indicates how many octets are
  138.    in the option field. It is calculated as:
  139.  
  140.            LENGTH = 2 + 4*(number of IP addresses)
  141.  
  142.    The remaining octets contain the IP addresses of the specified
  143.    destination hosts. Each IP address occupies 4 octets.
  144.  
  145. Transmission of SDBM datagrams
  146.  
  147.    The procedures for a source host, transit router, and destination
  148.    router are provided below. When a source host has a message to send
  149.    to multiple destination hosts, it shall,
  150.  
  151.    a. Group the destination host internet addresses by their network
  152.       identifiers (Net IDs). If there are N distinct Net IDs, there will
  153.       be at least N distinct directed broadcast packets. If there are
  154.       more that 9 destination hosts on a single net, multiple directed
  155.       broadcast datagrams must be sent to that net.
  156.  
  157.    b. For each Net ID, form the directed broadcast address as defined in
  158.       STD 3, RFC 1122 (Reference 3) for that network. The directed
  159.       broadcast address is used as the destination address in the IP
  160.       datagram and the source address is the address of the host sending
  161.       the message.
  162.  
  163.    c. Place the entire IP address for up to 9 destination hosts in the in
  164.       the same net in the option field defined above. The total length of
  165.       all IP options in a given datagram is limited to 40 octets as
  166.       determined by the HLEN (Header Length) field which defines the
  167.  
  168.  
  169.  
  170. Graff                                                           [Page 3]
  171.  
  172. RFC 1770         Selective Directed Broadcast Protocol        March 1995
  173.  
  174.  
  175.       number of 32 bit words in the header. If other options are to be
  176.       included in addition to the SDBM option, the number of addresses in
  177.       the option field must be reduced accordingly.
  178.  
  179.    d. The thusly formed datagram shall be transmitted and processed
  180.       according to normal datagram handling procedures.
  181.  
  182.    When a IP SDBM datagram encounters a transit router (router not
  183.    connected to the destination network), the datagram shall be
  184.    processed in accordance with normal IP datagram handling procedures.
  185.    When encountering the destination router (the destination network is
  186.    directly attached to the router), the destination router shall
  187.    perform a, b or c below:
  188.  
  189.    a. If the local subnet has a broadcast capability, broadcast to all
  190.       hosts in the network and let the hosts perform address filtering.
  191.  
  192.    b. If the local subnet does not support broadcast, form a local subnet
  193.       packet for each destination host in the SDBM datagram and transmit
  194.       into the network.
  195.  
  196.    c. If the local subnet supports reliable layer 2 multi-address
  197.       capability as provided by MIL-STD-188-220() networks, use a layer 2
  198.       multi-address frame to deliver the datagram to addresses found in
  199.       the IP option field.
  200.  
  201. Reception of SDBM datagrams
  202.  
  203.    In processing received SDBM datagrams, receiving hosts shall look
  204.    inside the IP option field for their address. Processing shall
  205.    continue only if the host's IP address is found inside this option
  206.    field. Thus the source host has explicit control over which hosts
  207.    will process its datagrams. Since SDBM uses a broadcast address in
  208.    its destination field, the SDBM can only be used with UDP (Reference
  209.    4) and not TCP (Reference 5) as the TCP supports only point-to-point
  210.    connections and not point-to-multi-point.
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Graff                                                           [Page 4]
  227.  
  228. RFC 1770         Selective Directed Broadcast Protocol        March 1995
  229.  
  230.  
  231. Source for MIL-STD-188-220()
  232.  
  233.    The above mentioned MIL-STD-188-220() may be obtained by contacting
  234.  
  235.    US Army Communications Electronics Command
  236.    AMSEL-RD-SE-AIN-E (ATTN: Mr. Ted Dzik)
  237.    Fort Monmouth, NJ 07703
  238.  
  239.    Comm: (908) 532-1780
  240.    Fax:  (908) 532-3398
  241.    EMail: DZIK@ain3.monmouth.army.mil
  242.  
  243. Acknowledgements
  244.  
  245.    The author wishes to acknowledge the major contributions to this work
  246.    made by Mr. Dave Macauley of ATT and Ms. Barbara Denny of SRI
  247.    International.  Other contributions were made by members of the 188-
  248.    220() committee.
  249.  
  250. References
  251.  
  252.    (1) "MIL-STD-188-220() For Task Force XXI, Interoperability Standard
  253.        for Digital Message Transfer Device Subsystems, 23 December 1994.
  254.  
  255.    (2) Postel, J., "Internet Protocol - DARPA Internet Program Protocol
  256.        Specification", STD 5, RFC 791, DARPA, September 1981.
  257.  
  258.    (3) Braden, R., Editor, "Requirements for Internet Hosts --
  259.        Communication Layers" STD 3, RFC 1122, IETF, October 1989.
  260.  
  261.    (4) Postel, J., "User Datagram Protocol", STD 6, RFC 768,
  262.        USC/Information Sciences Institute, August 1980.
  263.  
  264.    (5) Postel, J., "Transmission Control Protocol - DARPA Internet
  265.        Program Protocol Specification", STD 7, RFC 793, September 1981.
  266.  
  267. Security Considerations
  268.  
  269.        Security issues are not discussed in this memo.
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Graff                                                           [Page 5]
  283.  
  284. RFC 1770         Selective Directed Broadcast Protocol        March 1995
  285.  
  286.  
  287. Author's Address
  288.  
  289.        US Army Communications Electronics Command
  290.        AMSEL-RD-ST-LA-L ( ATTN: Charles Graff )
  291.        Ft. Monmouth, NJ 07703
  292.  
  293.        Phone: (908) 544 3264
  294.        Fax:   (908) 544 2150
  295.        EMail: bud@fotlan5.fotlan.army.mil
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Graff                                                           [Page 6]
  339.  
  340.