Transparent Interconnection of Lots of Links (trill)

Last Modified: 2008-07-02

Additional information is available at tools.ietf.org/wg/trill

Chair(s):

  • Erik Nordmark <erik.nordmark@sun.com>

  • Donald Eastlake 3rd <d3e3e3@gmail.com>

    Internet Area Director(s):

  • Jari Arkko <jari.arkko@piuha.net>
  • Mark Townsley <townsley@cisco.com>

    Internet Area Advisor:

  • Mark Townsley <townsley@cisco.com>

    Mailing Lists:

    General Discussion: rbridge@postel.org
    To Subscribe: http://www.postel.org/mailman/listinfo/rbridge
    Archive: http://www.postel.org/pipermail/rbridge

    Description of Working Group:

    The TRILL WG will design a solution for shortest-path frame routing in
    multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary
    topologies, using an existing link-state routing protocol technology.

    This work will initially be based on draft-perlman-rbridge-03.txt.

    The design should have the following properties:

    - Minimal or no configuration required
    - Load-splitting among multiple paths
    - Routing loop mitigation (possibly through a TTL field)
    - Support of multiple points of attachment
    - Support for broadcast and multicast
    - No significant service delay after attachment
    - No less secure than existing bridged solutions

    Any changes introduced to the Ethernet service model should be
    analyzed and clearly documented. To ensure compatibility with IEEE
    VLANs and the Ethernet service model, the WG will request an IEEE
    liaison relationship with IEEE 802.1, and IEEE 802.1 will be asked to
    review the architecture document and specification(s) before they are
    submitted to the IESG.

    It is not an explicit requirement that the solution should be able to
    run on existing IP routers or IEEE 802 switches as a software upgrade.
    However, the working group should take deployment considerations into
    account, to ensure that the solution can interwork with bridges in a
    flexible manner (e.g., to allow incremental deployment into LANs that
    currently use 802.1D bridges).

    The TRILL working will work with the L2VPN WG to develop interworking
    between TRILL and 802.1D bridges at the edge, such that a bridged
    sub-cloud could be attached to TRILL devices in more than one place
    for redundancy.

    The solution must not interfere with the end-to-end transparency of
    the Internet architecture or with end-to-end congestion control and
    QOS mechanisms.

    The WG will work on the following items:

    (1) Develop a problem statement and architecture document that
    describes the high-level TRILL architecture, discusses the
    scalability of that architecture, describes the threat model
    and security impacts of the TRILL solution, and describes the
    expected impacts (if any) of the TRILL solution on the Ethernet
    service model.

    (2) Define the requirements for a TRILL-capable routing protocol, and
    select one or more existing routing protocols that could meet
    those requirements.

    (3) Work with the appropriate Routing area working group to extend an
    existing routing protocol to meet the TRILL working group
    requirements.

    Note: The TRILL working group is not chartered to develop a new
    routing protocol or to make substantial modifications to an
    existing routing protocol. If, during the requirements definition
    and selection phase, the TRILL working group discovers that no
    existing routing protocol will meet their needs, we will need to
    re-assess the TRILL WG charter to determine how/if this work
    should proceed.

    (4) Produce a (set of) TRILL specification(s) for standards track
    publication that define(s) what information must be carried in an
    encapsulation header for data packets. Although this work will
    initially be undertaken only for 802.1-compliant links, it
    may later be expanded to non-802.1 links, so the design should be
    link-layer agnostic to whatever extent possible.

    The TRILL working group is chartered to undertake all of the above
    tasks and may begin work on more than one of these tasks in parallel.
    However, the problem statement and architecture document should be
    completed before the details of the base protocol are finalized, while
    there is still time to consider changes to the architecture without
    major impacts on established specifications.

    Goals and Milestones:

    Done  Accept base protocol specification as a WG document
    Done  Accept problem statement and applicability as a WG work item
    Done  Start work with routing area WG(s) to undertake TRILL extensions
    Done  Accept architecture document as a WG work item
    Done  Accept routing protocol requirements as a WG work item
    Done  Choose routing protocol(s) that can meet the requirements
    Dec 2007  Submit base protocol specification to IEEE/IETF expert review
    Dec 2007  Submit problem statement and applicability to IESG for Informational RFC
    Dec 2007  Submit architecture document to IEEE/IETF expert review
    Mar 2008  Submit architecture document to the IESG for publication as an Informational RFC
    Mar 2008  Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC
    Dec 2008  Re-charter or shut down the WG

    Internet-Drafts:

    Rbridges: Base Protocol Specification (176178 bytes)
    Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement (44280 bytes)

    No Request For Comments

    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.