📄 rfc2427.txt
字号:
In a Frame Relay network there must be a full mesh of Frame Relay VCs
between bridges of a remote bridge group. If the frame relay network
is not a full mesh, then the bridge network must be divided into
multiple remote bridge groups.
Brown & Malis Standards Track [Page 23]
RFC 2427 Multiprotocol over Frame Relay September 1998
The frame relay VCs that interconnect the bridges of a remote bridge
group may be combined or used individually to form one or more
virtual bridge ports. This gives flexibility to treat the Frame
Relay interface either as a single virtual bridge port, with all VCs
in a group, or as a collection of bridge ports (individual or grouped
VCs).
When a single virtual bridge port provides the interconnectivity for
all bridges of a given remote bridge group (i.e. all VCs are combined
into a single virtual port), the standard Spanning Tree Algorithm may
be used to determine the state of the virtual port. When more than
one virtual port is configured within a given remote bridge group
then an "extended" Spanning Tree Algorithm is required. Such an
extended algorithm is defined in IEEE 802.1g [13]. The operation of
this algorithm is such that a virtual port is only put into backup if
there is a loop in the network external to the remote bridge group.
The simplest bridge configuration for a Frame Relay network is the
LAN view where all VCs are combined into a single virtual port.
Frames, such as BPDUs, which would be broadcast on a LAN, must be
flooded to each VC (or multicast if the service is developed for
Frame Relay services). Flooding is performed by sending the packet to
each relevant DLC associated with the Frame Relay interface. The VCs
in this environment are generally invisible to the bridge. That is,
the bridge sends a flooded frame to the frame relay interface and
does not "see" that the frame is being forwarded to each VC
individually. If all participating bridges are fully connected (full
mesh) the standard Spanning Tree Algorithm will suffice in this
configuration.
Typically LAN bridges learn which interface a particular end station
may be reached on by associating a MAC address with a bridge port.
In a Frame Relay network configured for the LAN-like single bridge
port (or any set of VCs grouped together to form a single bridge
port), however, the bridge must not only associated a MAC address
with a bridge port, but it must also associate it with a connection
identifier. For Frame Relay networks, this connection identifier is
a DLCI. It is unreasonable and perhaps impossible to require bridges
to statically configure an association of every possible destination
MAC address with a DLC. Therefore, Frame Relay LAN-modeled bridges
must provide a mechanism to allow the Frame Relay bridge port to
dynamically learn the associations. To accomplish this dynamic
learning, a bridged packet shall conform to the encapsulation
described within section 4.2. In this way, the receiving Frame Relay
interface will know to look into the bridged packet to gather the
appropriate information.
Brown & Malis Standards Track [Page 24]
RFC 2427 Multiprotocol over Frame Relay September 1998
A second Frame Relay bridging approach, the point-to-point view,
treats each Frame Relay VC as a separate bridge port. Flooding and
forwarding packets are significantly less complicated using the
point-to-point approach because each bridge port has only one
destination. There is no need to perform artificial flooding or to
associate DLCIs with destination MAC addresses. Depending upon the
interconnection of the VCs, an extended Spanning Tree algorithm may
be required to permit all virtual ports to remain active as long as
there are no true loops in the topology external to the remote bridge
group.
It is also possible to combine the LAN view and the point-to-point
view on a single Frame Relay interface. To do this, certain VCs are
combined to form a single virtual bridge port while other VCs are
independent bridge ports.
The following drawing illustrates the different possible bridging
configurations. The dashed lines between boxes represent virtual
circuits.
+-------+
-------------------| B |
/ -------| |
/ / +-------+
/ |
+-------+/ \ +-------+
| A | -------| C |
| |-----------------------| |
+-------+\ +-------+
\
\ +-------+
\ | D |
-------------------| |
+-------+
Since there is less than a full mesh of VCs between the bridges in
this example, the network must be divided into more than one remote
bridge group. A reasonable configuration is to have bridges A, B,
and C in one group, and have bridges A and D in a second.
Configuration of the first bridge group combines the VCs
interconnection the three bridges (A, B, and C) into a single virtual
port. This is an example of the LAN view configuration. The second
group would also be a single virtual port which simply connects
bridges A and D. In this configuration the standard Spanning Tree
Algorithm is sufficient to detect loops.
Brown & Malis Standards Track [Page 25]
RFC 2427 Multiprotocol over Frame Relay September 1998
An alternative configuration has three individual virtual ports in
the first group corresponding to the VCs interconnecting bridges A, B
and C. Since the application of the standard Spanning Tree Algorithm
to this configuration would detect a loop in the topology, an
extended Spanning Tree Algorithm would have to be used in order for
all virtual ports to be kept active. Note that the second group
would still consist of a single virtual port and the standard
Spanning Tree Algorithm could be used in this group.
Using the same drawing, one could construct a remote bridge scenario
with three bridge groups. This would be an example of the point-to-
point case. Here, the VC connecting A and B, the VC connecting A and
C, and the VC connecting A and D are all bridge groups with a single
virtual port.
10. Security Considerations
This document defines mechanisms for identifying the multiprotocol
encapsulation of datagrams over Frame Relay. There is obviously an
element in trust in any encapsulation protocol - a receiver must
trust that the sender has correctly identified the protocol being
encapsulated. In general, there is no way for a receiver to try to
ascertain that the sender did indeed use the proper protocol
identification, nor would this be desired functionality.
It also specifies the use of ARP and RARP with Frame Relay, and is
subject to the same security constraints that affect ARP and similar
address resolution protocols. Because authentication is not a part
of ARP, there are known security issues relating to its use (e.g.,
host impersonation). No additional security mechanisms have been
added to ARP or RARP for use with Frame Relay networks.
Brown & Malis Standards Track [Page 26]
RFC 2427 Multiprotocol over Frame Relay September 1998
11. Appendix A - NLPIDS and PIDs
List of Commonly Used NLPIDs
0x00 Null Network Layer or Inactive Set
(not used with Frame Relay)
0x08 Q.933 [2]
0x80 SNAP
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0x8E IPv6
0xB0 FRF.9 Data Compression [14]
0xB1 FRF.12 Fragmentation [18]
0xCC IPv4
0xCF PPP in Frame Relay [17]
List of PIDs of OUI 00-80-C2
with preserved FCS w/o preserved FCS Media
------------------ ----------------- --------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs as defined by
802.1(d) or
802.1(g)[12].
0x00-0F Source Routing BPDUs
Brown & Malis Standards Track [Page 27]
RFC 2427 Multiprotocol over Frame Relay September 1998
12. Appendix B - Connection Oriented Procedures
This Appendix contains additional information and instructions for
using ITU Recommendation Q.933 [2] and other ITU standards for
encapsulating data over frame relay. The information contained here
is similar (and in some cases identical) to that found in Annex E to
ITU Q.933. The authoritative source for this information is in Annex
E and is repeated here only for convenience.
The Network Level Protocol ID (NLPID) field is administered by ISO
and the ITU. It contains values for many different protocols
including IP, CLNP (ISO 8473), ITU Q.933, and ISO 8208. A figure
summarizing a generic encapsulation technique over frame relay
networks follows. The scheme's flexibility consists in the
identification of multiple alternative to identify different
protocols used either by
- end-to-end systems or
- LAN to LAN bride and routers or
- a combination of the above.
over frame relay networks.
Q.922 control
|
|
--------------------------------------------
| |
UI I Frame
| |
--------------------------------- --------------
| 0x08 | 0x81 |0xCC | 0x80 |..01.... |..10....
| | | | | |
Q.933 CLNP IP SNAP ISO 8208 ISO 8208
| | Modulo 8 Modulo 128
| |
-------------------- OUI
| | |
L2 ID L3 ID -------
| User | |
| Specified | |
| 0x70 802.3 802.6
|
---------------------------
|0x51 |0x4E | |0x4C |0x50
| | | | |
7776 Q.922 Others 802.2 User
Specified
Brown & Malis Standards Track [Page 28]
RFC 2427 Multiprotocol over Frame Relay September 1998
For those protocols which do not have a NLPID assigned or do not have
a SNAP encapsulation, the NLPID value of 0x08, indicating ITU
Recommendation Q.933 should be used. The four octets following the
NLPID include both layer 2 and layer 3 protocol identification. The
code points for most protocols are currently defined in ITU Q.933 low
layer compatibility information element. The code points for "User
Specified" are described in Frame Relay Forum FRF.3.1 [15]. There is
also an escape for defining non-standard protocols.
Format of Other Protocols
using Q.933 NLPID
+-------------------------------+
| Q.922 Address |
+---------------+---------------+
| Control 0x03 | NLPID 0x08 |
+---------------+---------------+
| L2 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| L3 Protocol ID |
| octet 1 | octet 2 |
+---------------+---------------+
| Protocol Data⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -