Movatterモバイル変換


[0]ホーム

URL:


Wayback Machine
118 captures
06 Feb 2007 - 27 Dec 2024
JulOCTJan
Previous capture17Next capture
201320142015
success
fail
COLLECTED BY
Organization:Alexa Crawls
Starting in 1996,Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to theWayback Machine after an embargo period.
Collection:Alexa Crawls
Starting in 1996,Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to theWayback Machine after an embargo period.
TIMESTAMPS
loading
The Wayback Machine - https://web.archive.org/web/20141017111741/http://tools.ietf.org:80/html/rfc1770
[Docs] [txt|pdf]

Obsoleted by:6814 HISTORIC

Network Working Group                                           C. GraffRequest for Comments: 1770                                 US Army CECOMCategory: Informational                                       March 1995IPv4 Option for Sender Directed Multi-Destination DeliveryStatus 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 andGraff                                                           [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 LayoutGraff                                                           [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 theGraff                                                           [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 1995Source 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.milAcknowledgements   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 1995Author'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.milGraff                                                           [Page 6]

Html markup produced by rfcmarkup 1.108, available fromhttp://tools.ietf.org/tools/rfcmarkup/
[8]ページ先頭

©2009-2025 Movatter.jp