分享
 
 
 

RFC2269 - Using the MARS Model in non-ATM NBMA Networks

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

Network Working Group G. Armitage

Request for Comments: 2269 LUCent Technologies

Category: Informational January 1998

Using the MARS Model in non-ATM NBMA Networks

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

Initially developed for IP over ATM, the RFC2022 (MARS) model is

also applicable to other NBMA networks that provide the equivalent of

switched, point to multipoint connections. This short document is

intended to state the obvious equivalences, and eXPlain the less

obvious implications. No changes to the MARS model per se are

suggested or required. RFC2022 is not required over NBMA networks

that offer Ethernet-like group addressing functionality.

1. Introduction

Most network layer models, like the one described in STD 5, RFC1112

[1] for IP multicasting, assume sources may send their packets to an

abstract 'multicast group addresses'. Link layer support for such an

abstraction is assumed to exist, and is provided by technologies such

as Ethernet.

Some NBMA networks (e.g. ATM using UNI3.0 or UNI3.1 signaling [4,5])

do not support a multicast (or group) address abstraction. In these

environments multicasting is typically supported through point to

multipoint calls (or emulated with multiple point to point calls).

The MARS model (RFC2022) [2] was originally developed by the IP over

ATM working group, and so uses ATM-centric descriptive language. For

completeness this memo explains how RFC2022 can be applied to other

NBMA technologies.

2. RFC2022's basic assumptions.

Section 3 of [2] describes the basic assumptions that the MARS model

makes about the services available from the link layer network (using

ATM as the specific case). In summary these are:

The ATM model broadly describes an 'AAL User' as any entity that

establishes and manages VCs and underlying AAL services to

exchange data. An IP over ATM interface is a form of 'AAL User'

The most fundamental limitations of UNI 3.0/3.1's multicast

support are:

Only point to multipoint, unidirectional VCs may be

established.

Only the root (source) node of a given VC may add or remove

leaf nodes.

Leaf nodes are identified by their unicast ATM addresses.

Given this point to multipoint call service, the MARS document goes

on to describe two architectures for emulating multipoint to

multipoint IP multicasting - the VC Mesh, and the Multicast Server.

In either case it was assumed that IP/ATM interfaces (whether in

routers or hosts) are allowed to originate and manage outgoing point

to multipoint calls without network operator intervention or manual

provisioning.

The MARS document also specifies that AAL5 be used for all SVCs,

implying a requirement that the underlying link service supports the

atomic exchange of PDUs.

3. Generalising the MARS model.

Any NBMA service that offers an equivalent to (or superset of) the

ATM point to multipoint call service can use the MARS model directly.

It must be possible to transmit atomic data units bi-directionally

with point to point calls, and unidirectionally (from root to leaves)

on point to multipoint calls.

A MARS is an entity known by its NBMA address.

A MARS Client is an entity known by its NBMA address.

An MCS (where needed) is an entity known by its NBMA address.

The MARS control messages defined in sections 4 onwards of the MARS

document are shown carrying ATM addresses. Using different mar$afn

(Address Family) values in the fixed header of MARS control messages

allows MARS entities to indicate they are carrying other types of

NBMA addresses (as done in NHRP [3]). As for NHRP, the

interpretation of the 'sub-address' fields shall be in the context of

the address family selected (which means it will often simply be

null).

In all cases where {IP, ATM.1, ATM.2, ...} mappings are referred to,

they may be interpreted as {IP, NBMA.1, NBMA.2, ...} in the context

of whatever NBMA network you are deploying MARS.

The MARS Cluster is defined in [2] as:

The set of ATM interfaces chosing to participate in direct ATM

connections to achieve multicasting of AAL_SDUs between

themselves.

It is trivial to observe that the cluster definition is independent

of the underlying link layer technology. A revised definition

becomes:

The set of NBMA interfaces chosing to participate in direct NBMA

connections to achieve multicasting of packets between themselves.

The term 'Cluster Member' continues to refer to an endpoint that is

currently using a specific MARS for multicast support. The potential

scope of a cluster may be the entire membership of a LIS, while the

actual scope of a cluster depends on which LIS members are actually

registered with the cluster's MARS at any given time.

Section 3.4 of [2] provided a set of mneumonics for the signalling

functions available to AAL Users. These mneumonics are then used in

the remainder of [2] to indicate link layer events to which MARS

entities might react. Recast from the perspective of an NBMA based

MARS entity, the descriptions would now read:

The following generic signalling functions are presumed to be

available to local MARS entities:

L_CALL_RQ Establish a pt-pt call to a specific endpoint.

L_MULTI_RQ Establish pt-mpt call to a specific endpoint.

L_MULTI_ADD Add new leaf node to previously established pt-mpt

call.

L_MULTI_DROP Remove specific leaf node from established pt-mpt

call.

L_RELEASE Release pt-pt call, or all Leaves of a pt-mpt call.

The signalling exchanges and local information passed between MARS

entity and NBMA signalling entity with these functions are outside

the scope of this document.

The following indications are assumed to be available to MARS

entities, generated by by the local NBMA signalling entity:

L_ACK Succesful completion of a local request.

L_REMOTE_CALL A new call has been established to the MARS

entity.

ERR_L_RQFAILED A remote NBMA endpoint rejected an L_CALL_RQ,

L_MULTI_RQ, or L_MULTI_ADD.

ERR_L_DROP A remote NBMA endpoint dropped off an existing

call.

ERR_L_RELEASE An existing call was terminated.

The signalling exchanges and local information passed between MARS

entity and NBMA signalling entity with these functions are outside

the scope of this document.

4. Open Issues.

The trade offs between VC Mesh and Multicast Server modes may look

quite different for each NBMA technology. This will be especially

true in the area of VC (or equivalent) resource consumption in the

NICs of hosts, routers, and endpoints supporting MARSs or MCss. The

use of VC mesh mode is most vulnerable to NBMA technologies that are

signalling intensive or resource challenged.

Sizing of Clusters (and hence LISes) will also be affected by a given

NBMA network's ability to support lots of pt-mpt calls.

Additionally, you cannot have more members in a cluster than you can

have leaf nodes on a pt-mpt call, without hacking the MARS model [6].

On going developments in server synchronisation protocols for

distributed RFC2022 implementations are expected to be applicable to

non-ATM NBMA networks.

Quality of service considerations are outside the scope of this

document. They will be very specific to each NBMA technology's

capabilities. Related work is being pursued outside the ION Working

Group.

If the NBMA network offers some sort of native multipoint to

multipoint service then use of the MARS model may not be optimal.

Such situations require further analysis.

Security Considerations

This memo is informational, and specifies no protocol for deployment.

No specific non-ATM NBMA network technologies or security

characteristics are discussed. Should enhancements to security be

required, they shall be added as an extension to the base

architecture in RFC2022, or described in documents explicitly

proposing use of RFC2022 over specific NBMA technologies.

Acknowledgments

This memo was substantially developed while the author was with Bell

Communications Research (Bellcore).

Author's Address

Grenville Armitage

Bell Laboratories, Lucent Technologies.

101 Crawfords Corner Rd,

Holmdel, NJ, 07733

USA

EMail: gja@lucent.com

References

[1] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC

1112, Stanford University, August 1989.

[2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM

Networks.", RFC2022, November 1996.

[3] Luciani, J., et. al., "NBMA Next Hop Resolution Protocol (NHRP)",

Work in Progress.

[4] ATM Forum, "ATM User-Network Interface Specification Version

3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.

[5] ATM Forum, "ATM User Network Interface (UNI) Specification

Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs,

NJ, June 1995.

[6] Armitage, G., "Issues affecting MARS Cluster Size", RFC2121,

March 1997.

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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
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- 王朝網路 版權所有