📄 rfc2814.txt
字号:
check its path state and check whether it has stored a TCLASS
value. If so, it should include the TCLASS object in the outgoing
RESV message after performing its own admission control. If no
TCLASS value is stored, it must forward the RESV message without
inserting a TCLASS object.
* When a DSBM client (residing at an L3 device such as a host or an
edge router) receives the TCLASS object in a PATH message that it
accepts over an interface, it should store the TCLASS object as
part of its PATH state for the interface. Later, when the client
forwards a RESV message for the same session on the interface, the
client must include the TCLASS object (unchanged from what was
received in the previous PATH message) in the RESV message it
forwards over the interface.
* When a DSBM client receives a TCLASS object in an incoming RESV
message over a managed segment and local admission control
succeeds for the session for the outgoing interface over the
managed segment, the client must pass the user_priority value in
the TCLASS object to its local packet classifier. This will ensure
that the data packets in the admitted RSVP flow that are
subsequently forwarded over the outgoing interface will contain
the appropriate value encoded in their frame header.
Yavatkar, et al. Standards Track [Page 15]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
* When an L3 device receives a PATH or RESV message over a managed
segment in one L2 domain and it needs to forward the PATH/RESV
message over an interface outside that domain, the L3 device must
remove the TCLASS object (along with LAN_NHOP, RSVP_HOP_L2, and
LAN_LOOPBACK objects in the case of the PATH message) before
forwarding the PATH/RESV message. If the outgoing interface is on
a separate L2 domain, these objects may be regenerated according
to the processing rules applicable to that interface.
5. Detailed Message Processing Rules
5.1. Additional Notes on Terminology
* An L2 device may have several interfaces with attached segments
that are part of the same L2 domain. A switch in a L2 domain is an
example of such a device. A device which has several interfaces
may contain a SBM protocol entity that acts in different
capacities on each interface. For example, a SBM protocol entity
could act as a SBM on interface A, and act as a DSBM on interface
B.
* A SBM protocol entity on a layer 3 device can be a DSBM client,
and SBM, a DSBM, or none of the above (SBM transparent). Non-
transparent L3 devices can implement any combination of these
roles simultaneously. DSBM clients always reside at L3 devices.
* A SBM protocol entity residing at a layer 2 device can be a SBM, a
DSBM or none of the above (SBM transparent). A layer 2 device will
never host a DSBM client.
5.2. Use Of Reserved IP Multicast Addresses
As stated earlier, we require that the DSBM clients forward the RSVP
PATH messages to their DSBMs in a L2 domain before they reach the
next L3 hop in the path. RSVP PATH messages are addressed, according
to RFC-2205, to their destination address (which can be either an IP
unicast or multicast address). When a L2 device hosts a DSBM, a
simple-to-implement mechanism must be provided for the device to
capture an incoming PATH message and hand it over to the local DSBM
agent without requiring the L2 device to snoop for L3 RSVP messages.
In addition, DSBM clients need to know how to address SBM messages to
the DSBM. For the ease of operation and to allow dynamic DSBM-client
binding, it should be possible to easily detect and address the
existing DSBM on a managed segment.
Yavatkar, et al. Standards Track [Page 16]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
To facilitate dynamic DSBM-client binding as well as to enable easy
detection and capture of PATH messages at L2 devices, we require that
a DSBM be addressed using a logical address rather than a physical
address. We make use of reserved IP multicast address(es) for the
purpose of communication with a DSBM. In particular, we require that
when a DSBM client or a SBM forwards a PATH message over a managed
segment, it is addressed to a reserved IP multicast address. Thus, a
DSBM on a L2 device needs to be configured in a way to make it easy
to intercept the PATH message and forward it to the local SBM
protocol entity. For example, this may involve simply adding a static
entry in the device's filtering database (FDB) for the corresponding
MAC multicast address to ensure the PATH messages get intercepted and
are not forwarded further without the DSBM intervention.
Similarly, a DSBM always sends the PATH messages over a managed
segment using a reserved IP multicast address and, thus, the SBMs or
DSBM clients on the managed segments must simply be configured to
intercept messages addressed to the reserved multicast address on the
appropriate interfaces to easily receive PATH messages.
RSVP RESV messages continue to be unicast to the previous hop address
stored as part of the PATH state at each intermediate hop.
We define use of two reserved IP multicast addresses. We call these
the "AllSBM Address" and the "DSBMLogicalAddress". These are chosen
from the range of local multicast addresses, such that:
* They are not passed through layer 3 devices.
* They are passed transparently through layer 2 devices which are
SBM transparent.
* They are configured in the permanent database of layer 2 devices
which host SBMs or DSBMs, such that they are directed to the SBM
management entity in these devices. This obviates the need for
these devices to explicitly snoop for SBM related control packets.
* The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) and
224.0.0.17 (AllSBMAddress).
These addresses are used as described in the following table:
Type DSBMLogicaladdress AllSBMAddress
DSBM * Sends PATH messages * Monitors this address to detect
Client to this address the presence of a DSBM
Yavatkar, et al. Standards Track [Page 17]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
* Monitors this address to
receive PATH messages
forwarded by the DSBM
SBM * Sends PATH messages * Monitors and sends on this
to this address address to participate in
election of the DSBM
* Monitors this address to
receive PATH messages
forwarded by the DSBM
DSBM * Monitors this address * Monitors and sends on this
for PATH messages to participate in election
directed to it of the DSBM
* Sends PATH messages to this
address
The L2 or MAC addresses corresponding to IP multicast addresses are
computed algorithmically using a reserved L2 address block (the high
order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700]
gives additional details.
5.3. Layer 3 to Layer 2 Address Mapping
As stated earlier, DSBMs or DSBM clients residing at a L3 device must
include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2
devices along the path of a PATH message do not need to separately
determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP
object and its corresponding L2 address (for example, using ARP).
For the purpose of such mapping at L3 devices, we assume a mapping
function called "map_address" that performs the necessary mapping:
L2ADDR object = map_addr(L3Addr)
We do not specify how the function is implemented; the implementation
may simply involve access to the local ARP cache entry or may require
performing an ARP function. The function returns a L2ADDR object
that need not be interpreted by an L3 device and can be treated as an
opaque object. The format of the L2ADDR object is specified in
Appendix B.
5.4. Raw vs. UDP Encapsulation
We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for
encapsulating RSVP messages that are forwarded onto a L2 domain.
Thus, when a SBM protocol entity on a L3 device forwards a RSVP
message onto a L2 segment, it will only use RAW IP encapsulation.
Yavatkar, et al. Standards Track [Page 18]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
5.5. The Forwarding Rules
The message processing and forwarding rules will be described in the
context of the sample network illustrated in Figure 2.
Figure 2 - A sample network or L2 domain consisting of switched and
shared L2 segments
..........
.
+------+ . +------+ seg A +------+ seg C +------+ seg D +------+
| H1 |_______| R1 |_________| S1 |_________| S2 |_______| H2 |
| | . | | | | | | | |
+------+ . +------+ +------+ +------+ +------+
. | /
1.0.0.0 . | /
. |___ /
. seg B | / seg E
.......... | /
2.0.0.0 | /
+-----------+
| S3 |
| |
+-----------+
|
|
|
|
seg F | .................
------------------------------ .
| | | .
+------+ +------+ +------+ . +------+
| H3 | | H4 | | R2 |____________| H5 |
| | | | | | . | |
+------+ +------+ +------+ . +------+
.
. 3.0.0.0
.................
Figure 2 illustrates a sample network topology consisting of three IP
subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two
routers. The subnet 2.0.0.0 is an example of a L2 domain consisting
of switches, hosts, and routers interconnected using switched
segments and a shared L2 segment. The sample network contains the
following devices:
Yavatkar, et al. Standards Track [Page 19]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Device Type SBM Type
H1, H5 Host (layer 3) SBM Transparent
H2-H4 Host (layer 3) DSBM Client
R1 Router (layer 3) SBM
R2 Router (layer 3) DSBM for segment F
S1 Switch (layer 2) DSBM for segments A, B
S2 Switch (layer 2) DSBM for segments C, D, E
S3 Switch (layer 2) SBM
The following paragraphs describe the rules, which each of these
devices should use to forward PATH messages (rules apply to PATH_TEAR
messages as well). They are described in the context of the general
network illustrated above. While the examples do not address every
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -