📄 rfc1932.txt
字号:
Some examples of the latter are single VC per protocol binding,
TULIP, and TUNIC, discussed further in Section 4.
o The number and type of ATM administrative domains/networks, and
type of addressing used within an administrative domain/network.
In particular, in the single domain/network case, all attached
systems may be safely assumed to be using a single common
addressing format, while in the multiple domain case, attached
stations may not all be using the same common format,
with corresponding implications on address resolution. (See
Appendix A for a discussion of some of the issues that arise
when multiple ATM address formats are used in the same logical
IP subnet (LIS).) Also security/authentication is much more of a
concern in the multiple domain case.
IP over ATM proposals do not universally accept that IP routing over
an ATM network is required. Certain proposals rely on the following
assumptions:
o The widespread deployment of ATM within premises-based networks,
private wide-area networks and public networks, and
o The definition of interfaces, signaling and routing protocols
among private ATM networks.
The above assumptions amount to ubiquitous deployment of a seamless
ATM fabric which serves as the hub of a star topology around which
all other media is attached. There has been a great deal of
discussion over when, if ever, this will be a realistic assumption
for very large internetworks, such as the Internet. Advocates of
such approaches point out that even if these are not relevant to very
large internetworks such as the Internet, there may be a place for
such models in smaller internetworks, such as corporate networks.
The NHRP protocol (Section 8.2), not necessarily specific to ATM,
would be particularly appropriate for the case of ubiquitous ATM
deployment. NHRP supports the establishment of direct connections
across IP subnets in the ATM domain. The use of NHRP does not
require ubiquitous ATM deployment, but currently imposes topology
constraints to avoid routing loops (see Section 7). Section 8.2
Cole, Shur & Villamizar Informational [Page 6]
RFC 1932 IP over ATM: A Framework Document April 1996
describes NHRP in greater detail.
The Peer Model assumes that internetwork layer addresses can be
mapped onto ATM addresses and vice versa, and that reachability
information between ATM routing and internetwork layer routing can be
exchanged. This approach has limited applicability unless ubiquitous
deployment of ATM holds. The peer model is described in Section 8.4.
The Integrated Model proposes a routing solution supporting an
exchange of routing information between ATM routing and higher level
routing. This provides timely external routing information within
the ATM routing and provides transit of external routing information
through the ATM routing between external routing domains. Such
proposals may better support a possibly lengthy transition during
which assumptions of ubiquitous ATM access do not hold. The
Integrated Model is described in Section 8.5.
The Multiprotocol over ATM (MPOA) Sub-Working Group was formed by the
ATM Forum to provide multiprotocol support over ATM. The MPOA effort
is at an early stage at the time of this writing. An MPOA baseline
document has been drafted, which provides terminology for further
discussion of the architecture. This document is available from the
FTP server ftp.atmforum.com in pub/contributions as the file atm95-
0824.ps or atm95-0824.txt.
4. Encapsulations and Lower Layer Identification
Data encapsulation, and the identification of VC endpoints,
constitute two important issues that are somewhat orthogonal to the
issues of network topology and routing. The relationship between
these two issues is also a potential sources of confusion. In
conventional LAN technologies the 'encapsulation' wrapped around a
packet of data typically defines the (de)multiplexing path within
source and destination nodes (e.g. the Ethertype field of an
Ethernet packet). Choice of the protocol endpoint within the
packet's destination node is essentially carried 'in-band'.
As the multiplexing is pushed towards ATM and away from LLC/SNAP
mechanism, a greater burden will be placed upon the call setup and
teardown capacity of the ATM network. This may result in some
questions being raised regarding the scalability of these lower level
multiplexing options.
With the ATM Forum UNI version 3.1 service the choice of endpoint
within a destination node is made 'out of band' - during the Call
Setup phase. This is quite independent of any in-band encapsulation
mechanisms that may be in use. The B-LLI Information Element allows
Layer 2 or Layer 3 entities to be specified as a VC's endpoint. When
Cole, Shur & Villamizar Informational [Page 7]
RFC 1932 IP over ATM: A Framework Document April 1996
faced with an incoming SETUP message the Called Party will search
locally for an AAL User that claims to provide the service of the
layer specified in the B-LLI. If one is found then the VC will be
accepted (assuming other conditions such as QoS requirements are also
met).
An obvious approach for IP environments is to simply specify the
Internet Protocol layer as the VCs endpoint, and place IP packets
into AAL--SDUs for transmission. This is termed 'VC multiplexing' or
'Null Encapsulation', because it involves terminating a VC (through
an AAL instance) directly on a layer 3 endpoint. However, this
approach has limitations in environments that need to support
multiple layer 3 protocols between the same two ATM level endpoints.
Each pair of layer 3 protocol entities that wish to exchange packets
require their own VC.
Cole, Shur & Villamizar Informational [Page 8]
RFC 1932 IP over ATM: A Framework Document April 1996
RFC-1483 [6] notes that VC multiplexing is possible, but focuses on
describing an alternative termed 'LLC/SNAP Encapsulation'. This
allows any set of protocols that may be uniquely identified by an
LLC/SNAP header to be multiplexed onto a single VC. Figure 1 shows
how this works for IP packets - the first 3 bytes indicate that the
payload is a Routed Non-ISO PDU, and the Organizationally Unique
Identifier (OUI) of 0x00-00-00 indicates that the Protocol Identifier
(PID) is derived from the EtherType associated with IP packets
(0x800). ARP packets are multiplexed onto a VC by using a PID of
0x806 instead of 0x800.
.---------------.
: :
: IP Packet :
: :
---------------
: :
: :
8 byte header V V
.-------------.-------------.------------.---------------.
: : : : :
: : : : Encapsulated :
: 0xAA-AA-03 : 0x00-00-00 : 0x08-00 : Payload :
: : : : :
-------------^-------------^------------^---------------
: : : :
: (LLC) (OUI) (PID) : : :
V V V V
.----------------------------------------------------------.
: :
: AAL SDU :
: :
----------------------------------------------------------
Figure 1: IP packet encapsulated in an AAL5 SDU
Cole, Shur & Villamizar Informational [Page 9]
RFC 1932 IP over ATM: A Framework Document April 1996
.----------. .----------. .---------. .----------.
: : : : : : : :
: IP : : ARP : :AppleTalk: : etc... :
: : : : : : : :
---------- ---------- --------- ----------
^ : ^ : ^ : ^ :
: : : : : : : :
: V : V : V : V
.-----------------------------------------------------------.
: :
: 0x800 0x806 0x809 other :
: :
: Instance of layer using LLC/SNAP header to :
: perform multiplexing/demultiplexing :
: :
-----------------------------------------------------------
^ :
: :
: V
.------------------.
: :
: Instance of AAL5 :
: terminating :
: one VCC :
: :
------------------
Figure 2: LLC/SNAP encapsulation allows more than just
IP or ARP per VC.
Whatever layer terminates a VC carrying LLC/SNAP encapsulated traffic
must know how to parse the AAL--SDUs in order to retrieve the
packets. The recently approved signalling standards for IP over ATM
are more explicit, noting that the default SETUP message used to
establish IP over ATM VCs must carry a B-LLI specifying an ISO 8802/2
Layer 2 (LLC) entity as each VCs endpoint. More significantly, there
is no information carried within the SETUP message about the identity
of the layer 3 protocol that originated the request - until the
packets begin arriving the terminating LLC entity cannot know which
one or more higher layers are packet destinations.
Taken together, this means that hosts require a protocol entity to
register with the host's local UNI 3.1 management layer as being an
LLC entity, and this same entity must know how to handle and generate
LLC/SNAP encapsulated packets. The LLC entity will also require
mechanisms for attaching to higher layer protocols such as IP and
ARP. Figure 2 attempts to show this, and also highlights the fact
that such an LLC entity might support many more than just IP and ARP.
Cole, Shur & Villamizar Informational [Page 10]
RFC 1932 IP over ATM: A Framework Document April 1996
In fact the combination of RFC 1483 LLC/SNAP encapsulation, LLC
entities terminating VCs, and suitable choice of LLC/SNAP values, can
go a long way towards providing an integrated approach to building
multiprotocol networks over ATM.
The processes of actually establishing AAL Users, and identifying
them to the local UNI 3.1 management layers, are still undefined and
are likely to be very dependent on operating system environments.
Two encapsulations have been discussed within the IP over ATM working
group which differ from those given in RFC-1483 [6]. These have the
characteristic of largely or totally eliminating IP header overhead.
These models were discussed in the July 1993 IETF meeting in
Amsterdam, but have not been fully defined by the working group.
TULIP and TUNIC assume single hop reachability between IP entities.
Following name resolution, address resolution, and SVC signaling, an
implicit binding is established between entities in the two hosts.
In this case full IP headers (and in particular source and
destination addresses) are not required in each data packet.
o The first model is "TCP and UDP over Lightweight IP" (TULIP)
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -