分享
 
 
 

RFC1770 - IPv4 Option for Sender Directed Multi-Destination Delivery

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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

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, RFC791

(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

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, RFC1122 (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

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.

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, RFC791, DARPA, September 1981.

(3) Braden, R., Editor, "Requirements for Internet Hosts --

Communication Layers" STD 3, RFC1122, IETF, October 1989.

(4) Postel, J., "User Datagram Protocol", STD 6, RFC768,

USC/Information Sciences Institute, August 1980.

(5) Postel, J., "Transmission Control Protocol - DARPA Internet

Program Protocol Specification", STD 7, RFC793, September 1981.

Security Considerations

Security issues are not discussed in this memo.

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

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有