The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Role of policy in MTU signalling, updated draft
I've made some changes to the draft to better describe the role of
policy in adjusting MTU calculations. Please provide feedback for
this version vs the previous.
Thanks,
Ben
--
Network Working Group B. Black
Internet-Draft Layer8 Networks
Expires: May 15, 2002 K. Kompella
Juniper Networks
November 14, 2001
MTU Signalling Extensions for LDP
draft-black-ldp-mtu-extensions-02
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 15, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights
Reserved.
Abstract
Proper functioning of RFC 1191 path MTU detection requires
that IP routers have knowledge of the MTU for each link to
which they are connected [1]. As currently specified in
[3], LDP does not have the ability to signal the MTU for an
LSP to ingress LSRs.
This document specifies extensions to the LDP label
distribution protocol in support of LSP MTU signalling.
Black & Kompella Expires May 15, 2002 [Page 1]
Internet-Draft MTU Signalling Extensions for LDP November 2001
1. Introduction
As currently specified in [3], the LDP protocol for MPLS
does not support signalling of the MTU for LSPs to ingress
LSRs. This functionality is essential to the proper
functioning of RFC 1191 path MTU detection [1]. Without
knowledge of the MTU for an LSP, edge LSRs may transmit
packets along that LSP which are, according to [4], too big.
Such packets may be silently discarded by LSRs along the
LSP, effectively preventing communication between certain
end hosts.
The solution proposed in this document enables automatic
determination of the MTU for an LSP with the addition of a
TLV to carry MTU information for a FEC between adjacent LSRs
in LDP Label Mapping messages. This information is
sufficient for a set of LSRs along the path followed by an
LSP to discover either the exact MTU for that LSP, or an
approximation which is no worse than could be generated with
local information on the ingress LSR.
Black & Kompella Expires May 15, 2002 [Page 2]
Internet-Draft MTU Signalling Extensions for LDP November 2001
2. MTU Signalling
The signalling procedure described in this document employs
the addition of a single TLV to LDP Label Mapping messages
and a simple algorithm for LSP MTU calculation.
2.1 Signalling Procedure
The procedure for signalling the MTU is performed hop-by-hop
by each LSR L along an LSP. The steps are as follows:
1. First, L computes the MTU for each FEC:
1. If L is the egress LSR for the FEC, L set the MTU to
the MTU of the egress interface, unless local policy
specifies otherwise.
2. If L is not the egress LSR for the FEC, L SHOULD set
the MTU to 0xffff, indicating that it is not the
egress LSR and has not yet received an MTU other
than 0xffff from downstream LSRs. Local policy may
dictate the advertisement of a value other than
0xffff, but the default in the absence of such
policy should be 0xffff.
3. If L is not the egress LSR for a FEC, and receives a
Mapping for a FEC which includes an MTU TLV with a
value other than 0xffff, L calculates the MTU to
advertise according to the rules in Section 2.2. If
L receives multiple Mapping messages for this FEC,
it first chooses between them by some policy, then
applies the calculation for the chosen Mapping.
This is the "active Mapping" for this FEC.
4. If L receives a Mapping for a FEC without an MTU
State TLV from a directly connected neighbor, L MAY
act as if it received an MTU State TLV with MTU
0xffff, and follow the procedure in Step 1.2.
Otherwise, L MUST send Mappings for this FEC without
an MTU State TLV.
5. If L receives a Mapping for a FEC from a neighbor to
which it is not directly connected, it must first
find an LSP by which L can reach the neighbor.
(Note that this procedure may be recursively
applied.) Once the appropriate LSP has been
determined, the MTU is calculated as usual, using
the MTU of the selected LSP as the link MTU.
Black & Kompella Expires May 15, 2002 [Page 3]
Internet-Draft MTU Signalling Extensions for LDP November 2001
2. For each direct LDP neighbor of L to which L decides to
send a Mapping for a FEC, L attaches an MTU State TLV
with the MTU that it computed for this FEC. Mapping
messages sent to "remote" LDP neighbors need not have an
MTU State TLV.
3. When a new MTU is received for a label mapping from a
downstream LSR, or the active Mapping for a FEC changes,
L returns to Step 1. If the newly computed MTU is
unchanged, L does not advertise new information to its
neighbors.
This behavior is standard for attributes such as path
vector and hop count, and the same rules apply, as
specified in [3].
2.2 Calculating Local MTU
There is a wide variety of policies which may be used in
determining the MTU advertised by a node, however there are
restrictions which MUST be adhered to in order to ensure
proper operation of MTU signalling and minimization of
signalling traffic during topology changes.
If the local policy is based entirely on the egress
interface for the LSP, the calculated MTU must be less
than or equal to the egress interface MTU minus any label
overhead.
If the local policy is based on a group of egress
interfaces, the calculated MTU MUST be less than or equal
to the MTU of the egress interface with the largest MTU
in the group minus any label overhead, but SHOULD be less
than or equal to the MTU of the egress interface with the
smallest MTU in the group minus any label overhead.
Under no circumstances must the advertised MTU exceed the
received MTU.
2.3 MTU TLV
The MTU TLV encodes information on the maximum transmission
unit for an LSP, either for the entire path or only for a
segment of the path.
Black & Kompella Expires May 15, 2002 [Page 4]
Internet-Draft MTU Signalling Extensions for LDP November 2001
The encoding for the MTU TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| MTU TLV (0x0XXX) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MTU TLV
This is a 16-bit unsigned integer that represents the MTU in
bytes for an LSP or segment of an LSP.
Black & Kompella Expires May 15, 2002 [Page 5]
Internet-Draft MTU Signalling Extensions for LDP November 2001
3. Example of Operation
The figure and below describes a simple LSR topology. Ri
and Re are the ingress and egress LSRs for LSP P1. Rx and
Re are the ingress and egress LSRs for LSP P2. From Rx to
Re, LSP P1 is encapsulated in LSP P2. Ry is an intermediate
LSR which does not act as ingress or egress for any LSPs.
L1 through L3 are links connecting the LSRs.
MTU
Media w/ P2
+--+ +--+ +--+ +--+ Link MTU overhead
--|Ri|--L1--|Rx|--L2--|Ry|--L3--|Re|-- ---- ------ --------
+--+ +--+ +--+ +--+ L1 9216 9216
| | ^^ L2 4470 4466
| | || L3 9216 9212
| +---P2-------------+|
| |
+-------------P1--------------+
Figure 1. Sample LSR Topology
The following four time steps illustrate the calculation of
the MTU for P1. Let FEC F represent traffic mapped to LSP
P1.
At t[0]:
1) Re sets the MTU for F to 9216 (the MTU of the egress
interface) and sends a Mapping message for F to Ry.
2) Ri, Rx, and Ry have not received Mappings for F.
At t[1]:
1) Ry receives a Mapping for F from Re with an MTU of 9216.
Ry compares 9216 to (9212 - 4), and sends a Mapping message
for F with an MTU of 9208 to Rx.
2) Ri and Rx have not received Mappings for F.
At t[2]:
1) Rx receives a Mapping for F from Ry with an MTU of 9212.
Rx compares 9208 to (4466 - 4), and sends a Mapping message
for F with an MTU of 4462 to Ri.
Black & Kompella Expires May 15, 2002 [Page 6]
Internet-Draft MTU Signalling Extensions for LDP November 2001
2) Ri has not received Mappings for F.
At t[3]:
1) Ri receives a Mapping for F from Rx with an MTU of 4462.
Ri compares 4462 to (9216 - 4), and sets the MTU for P1 to
4462.
Black & Kompella Expires May 15, 2002 [Page 7]
Internet-Draft MTU Signalling Extensions for LDP November 2001
4. Protocol Interaction
4.1 Interaction With LSRs Which Do Not Support MTU Signalling
Changes in MTU for sections of an LSP may cause intermediate
LSRs to generate unsolicited label Mapping messages to
advertise the new MTU. LSRs which do not support MTU
signalling MUST accept these messages, but MAY ignore them
(see Section 2.1).
4.2 Interaction with CR-LDP and RSVP-TE
The MTU TLV can be used to discover the Path MTU of both LDP
LSPs and CR-LDP LSPs. This proposal is not impacted in the
presence of LSPs created using CR-LDP, as specified in [2].
Note that LDP/CR-LDP LSPs may tunnel through other LSPs
signalled using LDP, CR-LDP or RSVP-TE [5]; the mechanism
suggested here applies in all these cases.
Black & Kompella Expires May 15, 2002 [Page 8]
Internet-Draft MTU Signalling Extensions for LDP November 2001
5. Security Considerations
This mechanism does not introduce any new weaknesses in LDP.
It is possible to spoof TCP packets belonging to an LDP
session to manipulate the LSP MTU, but this sort of attack
is not new to LDP.
Black & Kompella Expires May 15, 2002 [Page 9]
Internet-Draft MTU Signalling Extensions for LDP November 2001
6. Acknowledgments
We would like to thank Andre Fredette for a number of
detailed comments on earlier versions of the signalling
mechanism. Danny McPherson and Vijay Gill also gave useful
feedback on earlier versions of the draft. Eric Gray has
contributed numerous useful suggestions.
Black & Kompella Expires May 15, 2002 [Page 10]
Internet-Draft MTU Signalling Extensions for LDP November 2001
References
[1] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1191, November 1990.
[2] Jamoussi, J., "Constraint-Based LSP Setup Using LDP",
July 2000.
[3] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
and B. Thomas, "LDP Specification", RFC 3036, January
2001.
[4] Rosen, E., Tappan, D., Federkow, G., Rekhter, Y.,
Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[5] Awduche, D., Berger, L. and D. Gan, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", February 2001.
Authors' Addresses
Benjamin Black
Layer8 Networks
EMail: ben@layer8.net
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
US
EMail: kireeti@juniper.net
Black & Kompella Expires May 15, 2002 [Page 11]
Internet-Draft MTU Signalling Extensions for LDP November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this document
itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it
into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by
the Internet Society.
Black & Kompella Expires May 15, 2002 [Page 12]
|
|