📄 rfc3034.txt
字号:
Conta, et al. Standards Track [Page 6]
RFC 3034 Label Switching with Frame Relay January 2001
The allowable ranges of DLCIs, the size of DLCIs, and the support for
VC merging MUST be communicated through LDP messages. Note that the
range of DLCIs used for labels depends on the size of the DLCI field.
5.2 Homogeneous LSPs
If <LSR1, LSR2, LSR3> is an LSP, it is possible that LSR1, LSR2, and
LSR3 will use the same encoding of the label stack when transmitting
packet P from LSR1, to LSR2, and then to LSR3. Such an LSP is
homogeneous.
5.3 Heterogeneous LSPs
If <LSR1, LSR2, LSR3> is an LSP, it is possible that LSR1 will use
one encoding of the label stack when transmitting packet P to LSR2,
but LSR2 will use a different encoding when transmitting a packet P
to LSR3. In general, the MPLS architecture supports LSPs with
different label stack encodings on different hops. When a labeled
packet is received, the LSR must decode it to determine the current
value of the label stack, then must operate on the label stack to
determine the new label value of the stack, and then encode the new
value appropriately before transmitting the labeled packet to its
next hop.
Naturally there will be MPLS networks which contain a combination of
Frame Relay switches operating as LSRs, and other LSRs, which operate
using other MPLS encapsulations, such as the Generic (MPLS shim
header), or ATM encapsulation. In such networks there may be some
LSRs, which have Frame Relay interfaces as well as MPLS Generic
("MPLS Shim") interfaces. This is one example of an LSR with
different label stack encodings on different hops of the same LSP.
Such an LSR may swap off a Frame Relay encoded label on an incoming
interface and replace it with a label encoded into a Generic MPLS
(MPLS shim) header on the outgoing interface.
5.4 Frame Relay Label Switching Loop Prevention and Control
FR-LSRs SHOULD operate on loop free FR-LSPs or LSP Frame Relay
segments. Therefore, FR-LSRs SHOULD use loop detection and MAY use
loop prevention mechanisms as described in [ARCH], and [LDP].
5.4.1 FR-LSRs Loop Control - MPLS TTL processing
The MPLS TTL encoded in the MPLS label stack is a mechanism used to:
(a) suppress loops;
(b) limit the scope of a packet.
Conta, et al. Standards Track [Page 7]
RFC 3034 Label Switching with Frame Relay January 2001
When a packet travels along an LSP, it should emerge with the same
TTL value that it would have had if it had traversed the same
sequence of routers without having been label switched. If the
packet travels along a hierarchy of LSPs, the total number of LSR-
hops traversed should be reflected in its TTL value when it emerges
from the hierarchy of LSPs [ARCH].
The initial value of the MPLS TTL is loaded into a newly pushed label
stack entry from the previous TTL value, whether that is from the
network layer header when no previous label stack existed, or from a
pre-existent lower level label stack entry.
A FR-LSR switching same level labeled packets does not decrement the
MPLS TTL. A sequence of such FR-LSR is a "non-TTL segment".
When a packet emerges from a "non-TTL LSP segment", it should however
reflect in the TTL the number of LSR-hops it traversed. In the
unicast case, this can be achieved by propagating a meaningful LSP
length or LSP Frame Relay segment length to the FR-LSR ingress nodes,
enabling the ingress to decrement the TTL value before forwarding
packets into a non-TTL LSP segment [ARCH].
When an ingress FR-LSR determines upon decrementing the MPLS TTL that
a particular packet's TTL will expire before the packet reaches the
egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch
the packet, but rather follow the specifications in [STACK] in an
attempt to return an error message to the packet's source:
- it treats the packet as an expired packet and return an ICMP
message to its source.
- it forwards the packet, as an unlabeled packet, with a TTL that
reflects the IP (network layer) forwarding.
If the incoming TTL is 1, only the first option applies.
In the multicast case, a meaningful LSP length or LSP segment length
is propagated to the FR-LSR egress node, enabling the egress to
decrement the TTL value before forwarding packets out of the non-TTL
LSP segment.
5.4.2 Performing MPLS TTL calculations
The calculation applied to the "input TTL" that yields the "output
TTL" depends on (i)the "input encapsulation", (ii)the "forwarding
encapsulation", and (iii)the "output encapsulation". The
relationship among (i),(ii), and (iii), can be defined as a function
Conta, et al. Standards Track [Page 8]
RFC 3034 Label Switching with Frame Relay January 2001
"D" of "input encapsulation" (ie), "forwarding encapsulation" (fe),
and "output encapsulation" (oe). Subsequently the calculation
applied to the "input TTL" to yield the "output TTL" can be described
as:
output TTL = input TTL - D(ie, fe, oe)
or in a brief notation:
output TTL = input TTL - d
where "d" has three possible values: "0","1", or "the number of hops
of the LSP segment":
For unicast transmission:
+================+=================+=================+=================+
| | Type of | Type of | Type of |
| d | Input | Forwarding | Output |
| | Encapsulation | Encapsulation | Encapsulation |
+================+=================+=================+=================+
| 0 | Frame Relay | Frame Relay | Frame Relay |
+----------------+-----------------+-----------------+-----------------+
| 1 | any | Generic MPLS | Generic MPLS |
+----------------+-----------------+-----------------+-----------------+
| number of hops | | Generic MPLS | |
| of | any | or | Frame Relay |
| LSP segment | |IP(network layer)| |
+================+=================+=================+=================+
The "number of hops of the LSP segment" is the value of the "hop
count" that is attached with the label used when the packet is
forwarded, if LDP [LDP] has provided such a "hop count" value when it
distributed the label for the LSP, that is the LDP message had a "hop
count object". If LDP didn't provide a "hop count", or it provided
an "unknown" value, the default value of the "number of hops of the
segment" is 1.
When sending a label binding upstream, the "hop count" associated
with the corresponding binding from downstream, if different than the
"unknown" value, MUST be incremented by 1, and the result transmitted
upstream as the hop count associated with the new binding (the
"unknown" value is transmitted unchanged). If the new "hop count"
value exceeds the "maximum" value, the FR-LSR MUST NOT pass the
binding upstream, but instead MUST send an error upstream
[LDP][ARCH].
Conta, et al. Standards Track [Page 9]
RFC 3034 Label Switching with Frame Relay January 2001
For multicast transmission:
+================+=================+=================+=================+
| | Type of | Type of | Type of |
| d | Input | Forwarding | Output |
| | Encapsulation | Encapsulation | Encapsulation |
+================+=================+=================+=================+
| 0 | Frame Relay | Frame Relay | Frame Relay |
+----------------+-----------------+-----------------+-----------------+
| | | Generic MPLS | |
| 1 | any | or | Frame Relay |
| | |IP(network layer)| |
+----------------+-----------------+-----------------+-----------------+
| number of hops | | Generic MPLS | |
| of | Frame Relay | or | any |
| LSP segment | |IP(network layer)| |
+================+=================+=================+=================+
Referring to the "forwarding encapsulation" with the abbreviation "I"
for IP (network layer), "G" for Generic MPLS, and "F" for Frame Relay
MPLS, referring to an LSR interface with the abbreviation "i" if the
input or output encapsulation is IP and no MPLS encapsulation, "g"
when the input or output MPLS encapsulation is Generic MPLS, "f" when
it is Frame Relay, "a" when it is ATM, and furthermore considering
the symbols "iIf", "gGf", "fFf", etc... as LSRs with input,
forwarding and output encapsulations as referred above, the following
describes examples of TTL calculations for the Homogeneous and
Heterogeneous LSPs discussed in previous sections:
Homogeneous LSP
---------------
IP_ttl = n IP_ttl=mpls_ttl-1 = n-6
--------->iIf fIi--------->
| mpls_ttl = n-5 ^
| |
number of hops 1| Frame Relay |5
| |
V 2 3 4 |
fFf--->fFf--->fFf--->fFf
"iIf" is "ingress LSR" in Frame Relay LSP and
calculates: mpls_ttl = IP_TTL - number of hops = n-5
"fIi" is "egress LSR" from Frame Relay LSP, and
calculates: IP_ttl = mpls_ttl-1 = n-6
Conta, et al. Standards Track [Page 10]
RFC 3034 Label Switching with Frame Relay January 2001
Heterogeneous LSP
-----------------
ingress LSR egress LSR
IP_ttl = n IP_ttl = n - 15
links LAN PPP FR ATM PPP FR LAN
--->iIg-->gGg-->gGf fGa aGg-->gGf fGg-->gIi--->
hops 1 2 | 6 | | 9 | 10 | 13 ^ 14 15
|1 4| |1 3| |1 3|
V 2 3 | V 2 | V 2 |
fFf-->fFf-->fFf aAa-->aAa fFf-->fFf
mpls_ttl
n-1 n-2 (n-2)-4=n-6 (n-6)-3=n-9 n-10 n-13 n-14
"iIg" is "ingress LSR" in LSP; it calculates: mpls_ttl=n-1
"gGf" is "egress LSR" from Generic MPLS segment, and
"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-6
"fGa" "egress LSR" from Frame Relay segment, and
"ingress LSR" in ATM segment and calculates: mpls_ttl=n-9
"gGf" is "egress LSR" from Generic MPLS segment, and
"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-13
"fGg" is "egress LSR" from Frame Relay segment, and
ingress LSR" in Generic MPLS segment and calculates: mpls_ttl=n-14
"gIi" is "egress LSR" from LSP and calculates: IP_ttl=n-15
And further examples:
Frame Relay Unicast -- TTL calculated at ingress
(ingress LSR) 1 2 3 4
x--->---+--->---+--->>--+-->>---x (egress LSR)
o.ttl=i.ttl-4 | 2 3
^
hops 1|
|
x (ingress LSR)
o.ttl=i.ttl-3
Frame Relay Multicast -- TTL calculated at egress
(egress LSR)x o.ttl=i.ttl-3
hops |
^3
(ingress LSR) | o.ttl=i.ttl-4
x--->---+--->---+--->---+--->---x (egress LSR)
1 2 3 4
Conta, et al. Standards Track [Page 11]
RFC 3034 Label Switching with Frame Relay January 2001
5.5 Label Processing by Ingress FR-LSRs
When a packet first enters an MPLS domain, the packet is forwarded by
normal network layer forwarding operations with the exception that
the outgoing encapsulation will include an MPLS label stack [STACK]
with at least one entry. The frame relay null encapsulation will
carry information about the network layer protocol implicitly in the
label, which MUST be associated only with that network protocol. The
TTL field in the top label stack entry is filled with the network
layer TTL (or hop limit) resulted after network layer forwarding
[STACK]. The further FR-LSR processing is similar in both possible
cases:
(a) the LSP is homogeneous -- Frame Relay only -- and the FR-LSR is
the ingress.
(b) the LSP is heterogeneous -- Frame Relay, PPP, Ethernet, ATM,
etc... segments form the LSP -- and the FR-LSR is the ingress into a
Frame Relay segment.
For unicast packets, the MPLS TTL SHOULD be decremented with the
number of hops of the Frame Relay LSP (homogeneous), or Frame Relay
segment of the LSP (heterogeneous). An LDP constructing the LSP
SHOULD pass meaningful information to the ingress FR-LSR regarding
the number of hops of the "non-TTL segment".
For multicast packets, the MPLS TTL SHOULD be decremented by 1. An
LDP constructing the LSP SHOULD pass meaningful information to the
egress FR-LSR regarding the number of hops of the "non-TTL segment".
Next, the MPLS encapsulated packet is passed down to the Frame Relay
data link driver with the top label as output DLCI. The Frame Relay
frame carrying the MPLS encapsulated packet is forwarded onto the
Frame Relay VC to the next LSR.
5.6 Label Processing by Core FR-LSRs
In a FR-LSR, the current (top) MPLS label is carried in the DLCI
field of the Frame Relay data link layer header of the frame. Just
as in conventional Frame Relay, for a frame arriving at an interface,
the DLCI carried by the Frame Relay data link header is looked up in
the DLCI Information Base, replaced with the correspondent output
DLCI, and transmitted on the outgoing interface (forwarded to the
next hop node).
Conta, et al. Standards Track [Page 12]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -