Internet Draft Document                            Vach Kompella
       Category: Standards Track                              Joe Regan
       Expires: August 2008                              Alcatel-Lucent
                                                           Shane Amante
                                                 Level 3 Communications
                                                      February 18, 2008
                     Conversation Hashing for Pseudowires
    Status of this Memo
       By submitting this Internet-Draft, each author represents that
       any applicable patent or other IPR claims of which he or she is
       aware have been or will be disclosed, and any of which he or she
       becomes aware will be disclosed, in accordance with Section 6 of
       BCP 79.
       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

       The list of Internet-Draft Shadow Directories can be accessed at

       This Internet-Draft will expire on August 21, 2008.
    Copyright Notice
          Copyright (C) The IETF Trust (2008).
       V. Kompella            Expires August 2008           [Page 1]

       Internet-Draft        Hashing on Pseudowires       February 2008
       This draft proposes a method to introduce granularity on the
       hashing of traffic running over pseudowires.  Most forwarding
       engines are able to hash based on label stacks, so the approach
       here is to introduce additional labels that do not affect the
       handling of packets, but which identify a conversation, and can
       be hashed with granularity.
    1. Introduction
       This draft proposes a method to introduce granularity on the
       hashing of traffic running over pseudowires.  Typically,
       forwarding hardware is capable of looking at some fields in
       packets to construct hash buckets for conversations or flows.
       The ingress node is able to look at the un-encapsulated packet
       and spread flows around.  At intermediate nodes, for
       pseudowires, there is no information on what layer 2 protocol
       encapsulation is on the packet, so the hardware can only hash on
       is the label stack.  However, the granularity obtained over
       pseudowires is inadequate for real load-balancing, especially
       when the pseudowires emulate fat trunks.
    2. The Solution
       When two PEs open up a targeted LDP session between them, as
       part of the Capability exchange between the two peers [LDP-Cap],
       the Hash Label TLV is exchanged.  The Hash Label TLV specifies a
       set of labels that instruct the receiving PE to POP and continue
       on to the next label in the stack.
       Since forwarding engines generate hash buckets based on the
       label stack, the Hash Label(s) can be used to provide some
       diversity in the conversations in a pseudowire.
       Suppose that an LDP session has been established between two
       peers, P and Q, and Q has signaled ten Hash Labels in the range
       101 through 110 (inclusive).  On receiving a packet from the
       attachment circuit, node P will hash the packet into one of ten
       buckets, one for each Hash Label received by P.  P will then
       encapsulate the packet with the PW label at the bottom of stack,
       add the appropriate Hash Label corresponding to the hash bucket,
       and finally add the tunnel encapsulation.  Assume for the moment
       that the tunnel encapsulation is another label.
       At P, the layer 2 fields are visible, and a next hop can be
       determined out of the multiple (e.g., ECMP or LAG) next hops.
       However, at an LSR node, the label stack provides more
       V. Kompella            Expires August 2008           [Page 2]

       Internet-Draft        Hashing on Pseudowires       February 2008
       variability, even though the packets belong to the same
       pseudowire because the Hash Label gives more diversity.
       The same set of labels used for hashing can be used between Q
       and any other node that it sets up a targeted LDP session, and
       the same set of labels can be used across different pseudowires.
       Note that this solution can be extended, e.g., if P is capable
       of imposing four labels, and if Q is capable of processing a
       four label stack, then P can hash the flows into 100 buckets
       (using two of the hash labels for the conversation diversity).
       This would also require that the intermediate nodes be capable
       of hashing a four label stack.
       The order of the labels must be PW label at the bottom, Router
       Alert (if present), and then the Hash Label(s).  Finally, the
       tunnel encapsulation comes at the top of the stack, which may be
       a label (or a pair of labels if the MPLS protocol imposes them,
       e.g., using facility bypass protection [RFC4090], or inter-area
       LDP [LDP-Ext]).
    2.1. Protocol Format
       We introduce a new Hash Label TLV which has the following
      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
     |U|F|  Hash Label TLV           |        Length                 |
     | NumPushLabels | NumPopLabels  | NumHashLabels |   AllocType   |
     |        MBZ            |    Label 1                            |
     |        MBZ            |    Label 2                            |
     |        MBZ            |      "                                |
       Hash Label TLV Type.
            The type of the Hash Label TLV (TBD from IANA).
            The length of the TLV.
       V. Kompella            Expires August 2008           [Page 3]

       Internet-Draft        Hashing on Pseudowires       February 2008
            The number of hash labels the node can push.
            The number of hash labels the node can pop.
            The number of hash labels provided for use.
            The type of allocation scheme.  If AllocType = 0, then the
       labels following the AllocType are a list of labels.  If
       AllocType = 1, then exactly two labels must follow the
       AllocType, and they provide the lower and upper bound of a range
       of labels (inclusive).
       Label 1, Label 2, etc.
            If AllocType = 0, these are actual labels that may be used
       as hash labels.  If AllocType = 1, then they are the lower and
       upper bound of a range of hash labels that may be used.
    3. Packet format with PW hash labels
       The following is an example of what could happen if hash labels
       are exchanged between two nodes P and Q, where P sends Q the
       Hash Label TLV with 10 labels between 101 and 110.
       The figure below shows the PW and tunnel labels.
                               PW label 2001
                       |         -----              |
                       |  ------>| C |-------       |
                       |  | 4000 ----- 7000 |       |
                       |  |                 v       v
                       -----    -----    -----    -----
               AC1-----| P |----| A |----| B |----| Q |-----AC2
                       -----    -----    -----    -----
                        |       ^   |    ^   |     ^
                        |       |   |    |   |     |
                        ---------   ------   -------
                          3000      5000      6000
       Tunnel Labels:
       P->A: 3000
       P->C: 4000
       A->B: 5000
       B->Q: 6000
       C->B: 7000
       V. Kompella            Expires August 2008           [Page 4]

       Internet-Draft        Hashing on Pseudowires       February 2008
       Q hashes a packet from attachment circuit AC2, on whatever
       relevant fields define a conversation or flow, and comes up with
       an index between 1 and 10, say 5.  Then Q constructs the packet
       to P to look like:
                       |         6000  (Tunnel Label)  |
                       |         105 (Hash Label)      |
                       |         2001 (PW Label) (BOS) |
                       |         Payload               |
       When B receives the packet, it will hash the label stack {6000,
       105, 2001} and come up with one of the next-hops A or C.  Say
       the result is A.  The packet from B to A will look like:
                       |         5000  (Tunnel Label)  |
                       |         105 (Hash Label)      |
                       |         2001 (PW Label) (BOS) |
                       |         Payload               |
       P would then receive the following packet from A:
                       |         3000  (Tunnel Label)  |
                       |         105 (Hash Label)      |
                       |         2001 (PW Label) (BOS) |
                       |         Payload               |
       P will pop 3000, find the hash label 105 (action pop), and then
       process 2001 as the PW label to forward the packet out AC1 with
       whatever necessary encapsulation is required for that DLC.
       V. Kompella            Expires August 2008           [Page 5]

       Internet-Draft        Hashing on Pseudowires       February 2008
       The rationale for putting the hash label between the PSN tunnel
       encapsulation and the PW label is that the forwarding engine
       will not have to process the PW label and then after it has
       taken the appropriate action, be required to remember the
       context while it processes the hash labels.
    4. Future considerations
       One future application of this method would be to create a basis
       for hash diversity without having to peek below the label stack
       for IP traffic carried over LDP LSPs.
    5. References
       Normative References
       Informative References
       [LDP-Cap] "LDP Capabilities," R. Thomas et al, draft-ietf-mpls-
       ldp-capabilities-01.txt, work in progress, February 2008.
       [RFC4090] "Fast Reroute Extensions to RSVP-TE for LSP Tunnels,"
       P. Pan, RFC 4090, May 2005.
       [LDP-Ext] "LDP extension for Inter-Area LSP," B. Decraene et al,
       draft-ietf-mpls-ldp-interarea-02.txt, work in progress, February
    6. Security Considerations
       No new security issues arise out of the extensions proposed here
       than exist in the base PWE3 standards.
    7. IANA Considerations
       No IANA allocations have been specified yet (but a new TLV type
       will be forthcoming, as well as changes to the LDP Capability
       FEC TLV).
    8. Authors' Addresses
       Vach Kompella
       V. Kompella            Expires August 2008           [Page 6]

       Internet-Draft        Hashing on Pseudowires       February 2008
       Joe Regan
       Shane Amante
       Level 3 Communications
    9. Full Copyright Statement
       Copyright (C) The IETF Trust (2008).
       This document is subject to the rights, licenses and
       restrictions contained in BCP 78, and except as set forth
       therein, the authors retain all their rights.
       This document and the information contained herein are provided
    10. Intellectual Property
       The IETF takes no position regarding the validity or scope of
       any Intellectual Property Rights or other rights that might be
       claimed to pertain to the implementation or use of the
       technology described in this document or the extent to which any
       license under such rights might or might not be available; nor
       does it represent that it has made any independent effort to
       identify any such rights.  Information on the procedures with
       respect to rights in RFC documents can be found in BCP 78 and
       BCP 79.
       Copies of IPR disclosures made to the IETF Secretariat and any
       assurances of licenses to be made available, or the result of an
       attempt made to obtain a general license or permission for the
       use of such proprietary rights by implementers or users of this
       specification can be obtained from the IETF on-line IPR
       repository at
       The IETF invites any interested party to bring to its attention
       any copyrights, patents or patent applications, or other
       proprietary rights that may cover technology that may be
       required to implement this standard.  Please address the
       information to the IETF at
       V. Kompella            Expires August 2008           [Page 7]

       Internet-Draft        Hashing on Pseudowires       February 2008
    11. Acknowledgments
       Funding for the RFC Editor function is provided by the IETF
       Administrative Support Activity (IASA).
       V. Kompella            Expires August 2008           [Page 8]