📄 rfc2427.txt
字号:
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 199811. 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 BPDUsBrown & Malis Standards Track [Page 27] RFC 2427 Multiprotocol over Frame Relay September 199812. 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 SpecifiedBrown & 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 | +-------------------------------+ | FCS | +-------------------------------+ ISO 8802/2 with user specified layer 3 +-------------------------------+ | Q.922 Address | +---------------+---------------+ | Control 0x03 | NLPID 0x08 | +---------------+---------------+ | 802/2 0x4C | 0x80 | +---------------+---------------+ |User Spec. 0x70| Note 1 | +---------------+---------------+ | DSAP | SSAP | +---------------+---------------+ | Control (Note 2) | +-------------------------------+ | Remainder of PDU | +-------------------------------+ | FCS | +-------------------------------+Brown & Malis Standards Track [Page 29] RFC 2427 Multiprotocol over Frame Relay September 1998 Note 1: Indicates the code point for user specified layer 3 protocol. Note 2: Control field is two octets for I-format and S-format frames (see 88002/2) Encapsulations using I frame (layer 2) The Q.922 I frame is for supporti⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -