Subject: LDP MTU Extensions (draft-black-ldp-mtu-extensions-00.txt)

From: Ben Black <[email-masked]>
Date: Fri, 22 Dec 2000 21:03:44 -0800

This was submitted to internet-drafts but has not yet posted.  It can also
be found at http://www.layer8.net/~ben/draft-black-ldp-mtu-extensions-00.txt.

Ben
--

Network Working Group                                    Benjamin Black
Internet Draft                                                 InterNAP
Expiration Date: June 2001                             Kireeti Kompella
                                                       Juniper Networks

                   MTU Signalling Extensions for LDP

                 draft-black-ldp-mtu-extensions-00.txt

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.

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.  As currently specified in [LDP], 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                                                [Page 1]

Internet Draft      draft-black-ldp-mtu-extensions-00.txt      June 2001

1. Overview

   As currently specified in [LDP], 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 for TCP sessions.  Without knowledge of
   the MTU for an LSP, edge LSRs may transmit packets along that
   LSP which are, according to [MPLS-ENC], too big.  Such packets
   may be silently discarded by LSRs along the LSP, effectively
   preventing reliable TCP sessions for 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.

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.

          a) Suppose L is the egress for a FEC.  L sets the MTU for this
             FEC to 0xffff.

          b) Suppose L receives a Mapping for a FEC with an MTU State
             TLV with MTU M and over an interface with MTU X.  L sets
             its MTU for this FEC (in octets) to the smaller of M and
             (X - 4).

             If L receives multiple Mapping messages for this FEC, it
             first chooses between them by some policy, then applies the
             above calculation for the chosen Mapping.  This is the
             "active Mapping" for this FEC.

Black & Kompella                                                [Page 2]

Internet Draft      draft-black-ldp-mtu-extensions-00.txt      June 2001

          c) 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 1b.  Otherwise, L MUST send Mappings for
             this FEC without an MTU State TLV.

          d) 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.)  Suppose that LSP has MTU M.
             The LSR then sets the MTU for the FEC to (M - 4).

      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.

2.2. MTU State TLV

   The MTU State TLV encodes information on the maximum transmission
   unit for an LSP, either for the entire path or only for a segment
   of the path.

   The encoding for the MTU State 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 State TLV (0x0XXX)  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              MTU              |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     MTU
       This is a 16-bit unsigned integer that represents the MTU in
       bytes for a link, from the perspective of the downstream LSR.

Black & Kompella                                                [Page 3]

Internet Draft      draft-black-ldp-mtu-extensions-00.txt      June 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 this F to 0xffff 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 0xffff.
         Ry compares 0xffff 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                                                [Page 4]

Internet Draft      draft-black-ldp-mtu-extensions-00.txt      June 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.

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/RSVP-TE

   The MTU State 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 [CR-LDP].
 
   Note that LDP/CR-LDP LSPs may tunnel through other LSPs signalled
   using LDP, CR-LDP or RSVP-TE [RSVP-TE]; the mechanism suggested here
   applies in all these cases.

5. Security Considerations

   The procedure and TLV proposed in this document do not raise any
   new security concerns.

6. Acknowledgements

   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.

7. References

   [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using
   LDP", draft-ietf-mpls-cr-ldp-04.txt (work in progress)

Black & Kompella                                                [Page 5]

Internet Draft      draft-black-ldp-mtu-extensions-00.txt      June 2001

   [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
   Thomas, B., "LDP Specification", draft-ietf-mpls-ldp-11.txt (work
   in progress)

   [MPLS-ENC] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G.
   Fedorkow, T. Li, A. Conta, "MPLS Label Stack Encoding",
   draft-ietf-mpls-label-encaps-08.txt (work in progress)

   [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
   Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
   draft-ietf-mpls-rsvp-lsp-tunnel-07.txt (work in progress)  

10. Authors' Addresses

      Benjamin Black
      InterNAP Network Services
      Two Union Square, Suite 1000
      601 Union Street
      Seattle, WA 98101
      email: [email-masked]

      Kireeti Kompella 
      Juniper Networks, Inc.
      1194 N. Mathilda Ave
      Sunnyvale, CA 94089
      email: [email-masked] 

Black & Kompella                                                [Page 6]