rfc1768.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 1,428 行 · 第 1/5 页
TXT
1,428 行
group Network address. The allocation of group addresses is
restricted to be only from the AFI values allocated for the
assignment of group addresses in Table 1. An addressing authority in
allocating either Network addresses or authorizing one or more
authorities to allocate addresses, allocates both individual and the
corresponding group addresses. Thus each block of addresses allocated
by an addressing authority (or its sub-authority) contains a block of
individual Network addresses and group Network addresses. The
individual and group address block allocated are differentiated by
the AFI values used which are related as shown in Table 1.
Group Network addresses are only used as the destination address
parameter of a CLNP PDU. Source Address parameters are never
permitted to be group Network addresses.
Table 2 lists the AFI values which have not been assigned, at this
time, for the support of neither individual nor group address
allocation. Future assignment of these AFI values is possible.
Additional information concerning individual Network addresses (i.e.,
NSAP and NET (Network Entity Titles)) is contained in RFC 1237.
Note: While the format of the Initial Domain Part of a group Network
address is assigned, the format for the Domain Specific Part of the
group Network address is specified by an addressing authority and is
out of the scope of this memo. While NSAP address assignments are
typically made to support hierarchical unicast routing, a similar
consideration for group Network address assignments may not exist.
Marlow [Page 6]
RFC 1768 CLNP Multicasting March 1995
TABLE 1 - Relationship of AFI Individual and Group Values
-----------------------------------------------------------
|Individual Group | Individual Group | Individual Group |
-----------------------------------------------------------
| 0x FF | | |
| 10 A0 | 40 BE | 70 DC |
| 11 A1 | 41 BF | 71 DD |
| 12 A2 | 42 C0 | 72 DE |
| 13 A3 | 43 C1 | 73 DF |
| 14 A4 | 44 C2 | 74 E0 |
| 15 A5 | 45 C3 | 75 E1 |
| 16 A6 | 46 C4 | 76 E2 |
| 17 A7 | 47 C5 | 77 E3 |
| 18 A8 | 48 C6 | 78 E4 |
| 19 A9 | 49 C7 | 79 E5 |
| 20 AA | 50 C8 | 80 E6 |
| 21 AB | 51 C9 | 81 E7 |
| 22 AC | 52 CA | 82 E8 |
| 23 AD | 53 CB | 83 E9 |
| 24 AE | 54 CC | 84 EA |
| 25 AF | 55 CD | 85 EB |
| 26 B0 | 56 CE | 86 EC |
| 27 B1 | 57 CF | 87 ED |
| 28 B2 | 58 D0 | 88 EE |
| 29 B3 | 59 D1 | 89 EF |
| 30 B4 | 60 D2 | 90 F0 |
| 31 B5 | 61 D3 | 91 F1 |
| 32 B6 | 62 D4 | 92 F2 |
| 33 B7 | 63 D5 | 93 F3 |
| 34 B8 | 64 D6 | 94 F4 |
| 35 B9 | 65 D7 | 95 F5 |
| 36 BA | 66 D8 | 96 F6 |
| 37 BB | 67 D9 | 97 F7 |
| 38 BC | 68 DA | 98 F8 |
| 39 BD | 69 DB | 99 F9 |
-----------------------------------------------------------
Marlow [Page 7]
RFC 1768 CLNP Multicasting March 1995
TABLE 2 - AFI values reserved for future allocation
--------------
| 1A-1F |
| 2A-2F |
| 3A-3F |
| 4A-4F |
| 5A-5F |
| 6A-6F |
| 7A-7F |
| 8A-8F |
| 9A-9F |
| FA-FE |
--------------
4. Model of a CLNP End System Multicast Implementation
The use of multicast transmission by a CLNP End System involves
extensions to two protocols: CLNP and the ES-IS Routeing Protocol. To
provide level 0 service (no support for CLNP multicast), no
extensions to these two protocols are required. To provide level 1
service (support for sending but not receiving CLNP multicast PDUs)
all extensions contained in the following sections are required
except for those supporting only Multicast Announcement. In order to
support level 2 service (full support for CLNP multicasting), the
extensions contained in the following sections are required.
Extensions identified for Intermediate Systems are not required (or
appropriate) for End Systems. Multicast transmission also requires
the use of a group Network address (as previously described) as the
destination address parameter.
5. Extensions to the CLNP protocol
This section provides extensions to the CLNP Protocol [CLNP] ISO
8473-1, to support multicast transmission. These additions provide
procedures for the connectionless transmission of data and control
information from one network-entity to one or more peer network-
entities.
In developing the multicast extensions for CLNP a decision was needed
on how to "mark" a packet as multicast (versus the current unicast
packets). Such marking is necessary since the forwarding behavior
for multicast packets is different (e.g., multiple copies of a packet
may need to be forwarded). The two alternatives considered were to
mark the packet (via a particular field) or to mark the destination
address, in the end both were done. The destination address for a
multicast PDU identifies a host group which is of a very different
nature than the unicast NSAP address. Rather than changing the
Marlow [Page 8]
RFC 1768 CLNP Multicasting March 1995
nature of NSAP addresses, a new set of addresses were created named
group Network addresses which are marked within the first octet
(i.e., the AFI field) with values reserved for group Network
addresses.
Consideration was given to no further marking of the PDU; however, a
problem was identified with only using the group Network address to
identify multicast packets. Currently routers implementing the IS-IS
Intra-Domain protocol as Level 1 routers when receiving a packet with
an unknown destination address are permitted to either discard the
packet or send it to a Level 2 router. Such actions by non-multicast
capable routers to multicast packets can lead to non-deterministic
behavior. Level 1 routers upon receiving a packet containing a group
Network address might pass the packet up to a Level 2 router (which
may or may not be multicast capable) or it might discard it.
Depending upon the circumstances this might lead to whole regions
missing packets or packet duplication (possibly even explosion). The
result was to seek deterministic behavior by non-multicast capable
routers by creating a new PDU type (Multicast Data PDU) and inserting
into the CLNP reasons for discard: receiving a PDU of unknown type.
Note that this reason for discard is mandatory on multicast capable
and non-multicast capable CLNP implementations.
5.1 Definitions
multicast: Data transmission to one or more destinations in a
selected group in a single service invocation.
multicast capable Intermediate System: An Intermediate System which
incorporates the multicast features of the Network layer.
5.2 Addresses
The destination address parameter of a multicast PDU shall contain a
group Network address. The source address parameter shall be an
individual Network address.
5.3 Extensions to the current protocol functions
In order to support multicast transmissions the following optional
CLNP protocol functions will be implemented:
5.3.1 Header Format Analysis function
The header format analysis function optionally provides capabilities
to Network entities which support multicast transfer to supply
applicable PDUs directly to End Systems served by such a Network
entity as well as to forward such PDUs on to other Network entities.
Marlow [Page 9]
RFC 1768 CLNP Multicasting March 1995
This optional functionality is realized through a Network entity with
multicast capability identifying a PDU as using multicast transfer
via the PDU type and the PDU's destination address field.
If a Network entity supports multicast transmission, then the header
format analysis function shall provide checking to ensure that a PDU
does not contain a group Network address in the source address field.
Any PDU header analyzed to have a group address in the source address
field shall be discarded.
5.3.2 Route PDU function
The route PDU function optionally provides capabilities to Network
entities which support multicast transfer for determining multiple
Network entities to which a single PDU shall be forwarded to. This
may result in multiple invocations of the forward PDU function and
hence the need to make multiple copies of the PDU. For PDUs that are
received from a different Network entity, the optional functionality
for the route PDU function is realized as a result of the header
format analysis function's recognition of the PDU as being a
multicast PDU. A Network entity attached to more than one subnetwork
when originating a multicast PDU is permitted to originate the PDU on
more than one subnetwork.
Note: The ES-IS function "Extensions to the ISO CLNP Route Function
by End Systems" discussed in section 6.10 identifies on which
subnetworks an End System attached to more than one subnetwork must
originate multicast PDUs on.
Note: The purpose in allowing an originating Network entity to
originate a multicast PDU on multiple subnetworks is to support the
development of multicast IS-IS protocols which will need to determine
on which subnetworks a multicast PDU has visited. This behavior is
predicated on the assumption that the Intermediate Systems in the OSI
environment performing multicast forwarding form a connected set.
5.3.3 Forward PDU function
This function issues an SN-UNITDATA request primitive, supplying the
subnetwork or Subnetwork Dependent Convergence Function (SNDCF)
identified by the route PDU function with the protocol data unit as
user data to be transmitted, the address information required by that
subnetwork or SNDCF to identify the "next" system or systems within
the subnetwork-specific addressing domain (this may be one or more
Intermediate Systems and/or one or more destination End Systems), and
quality of service constraints (if any) to be considered in the
processing of the user data.
Marlow [Page 10]
RFC 1768 CLNP Multicasting March 1995
5.3.4 Discard PDU function
Add an additional reason for discard - a PDU is received with an
unknown type code.
5.3.5 Error reporting function
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?