1 / 11

TRILL Working Group

TRILL Working Group. Changes from draft-trill-rbridge-protocol-02.txt to draft-trill-rbridge-protocol-03.txt Dinesh Dutt, Cisco Silvano Gai, Nuova Radia Perlman, Sun. Added the RBridge Model.

josephmoon
Download Presentation

TRILL Working Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TRILL Working Group Changes fromdraft-trill-rbridge-protocol-02.txt to draft-trill-rbridge-protocol-03.txt Dinesh Dutt, Cisco Silvano Gai, Nuova Radia Perlman, Sun 68th IETF - Prague

  2. Added the RBridge Model +----------------------------------------------------------+ | Higher Layer Entities | +--+--------------+----------------------+--------------+--+ | \ Trill Layer | RBridge Relay Entity | Trill Layer / | +----+------------+----------------------+------------+----+ | Data Link Layer | | Data Link Layer | +-----------------+ +-----------------+ | Physical Layer | | Physical Layer | +-------+---------+ +-------+---------+ | | P1 P2 • An Rbridge Relay Entity that interconnects two Rbridge ports; • At least one port (two in the example); • Higher Layer Entities, including at least the IS-IS protocol. • The TRILL Layer. An RBridge encapsulates incoming IEEE 802.3 frames (in this document also referred to as Ethernet frames) with a TRILL header to forward them to other Rbridges. 68th IETF - Prague

  3. Added examples of Encapsulations +--------------------------------+ | Outer Ethernet Header | +--------------------------------+ | TRILL Header | +--------------------------------+ | Inner Ethernet Header | +--------------------------------+ | Ethernet Payload | +--------------------------------+ | Ethernet FCS | +--------------------------------+ +--------------------------------+ | PPP Header | +--------------------------------+ | TRILL Header | +--------------------------------+ | Inner Ethernet Header | +--------------------------------+ | Ethernet Payload | +--------------------------------+ | Ethernet FCS | +--------------------------------+ 68th IETF - Prague

  4. Defined the term Multi-Destination • It identifies: 1. frames for unknown unicast destinations: the Inner.MacDa is unicast, but the ingress RBridge does not know its location; 2. frames for layer 2 multicast addresses derived from IP multicast addresses: the Inner.MacDa is multicast; 3. frames for layer 2 multicast addresses not derived from IP multicast addresses: the Inner.MacDa is multicast; 4. frames for the layer 2 broadcast addresses: the Inner.MacDa is broadcast; 5. ARP queries: the Inner.MacDa is broadcast; 6. ND queries: the Inner.MacDa is multicast; 68th IETF - Prague

  5. TRILL Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Hop Limit |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress RBridge Address | Egress RBridge Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • V (Version): 2-bit. See Section 3.1.1. • Hop Limit: 6-bit unsigned integer. See Section 3.1.3. • M (Multi-destination): 1-bit. See Section 3.1.2. • Reserved: 7-bit. • Ingress RBridge Address: 16-bit address. See Section 3.1.4.2. • Egress RBridge Address: 16-bit address. See Section 3.1.4.1. 68th IETF - Prague

  6. Added Ethernet Encapsulation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = IEEE 802.1Q | UP |C| Outer VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = TRILL | V | Hop Limit |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress RBridge Address | Ingress RBridge Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | InnerSource MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = IEEE 802.1Q | UP |C| Inner VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Original Ethernet Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68th IETF - Prague

  7. Added IVLAN and OVLAN • The Outer VLAN Tag: MAY or MAY NOT be present. If present, it is used to enable two RBridges to become adjacent through an Ethernet cloud that support VLANs. • The Inner VLAN Tag: contains the VLAN information associated with the original frame. • Clarified that in the rest of the document the term VLAN means inner VLAN. 68th IETF - Prague

  8. MAY, SHOULD, MUST (1) • Changed some text to utilize RFC2119 terms: • an RBridge MAY suppress the inner VLAN tag for frames with VID = 1. • some RBridges MAY be configured to not be the root of distribution tree • If Ri is a tree root, then any RBridge Rn that needs to send multi-destination traffic MAY select the Ri-tree • An Ingress RBridge MUST flood an ARP/ND query if the target is unknown, but MAY do so for a known target if it wants to assure freshness of the information… • RBridges MUST calculate at least one distribution tree, and by default compute one distribution tree for every Rbridge. 68th IETF - Prague

  9. MAY, SHOULD, MUST (2) • RBridges: • SHOULD store a successfully acquired nickname in non-volatile memory and attempt to reuse it on reboot • SHOULD implement an "optimized ARP/ND response" • MUST learn the location of endnodes. • MUST calculate a distribution tree for every RBridge with RequestTree TRUE or for the RBridge with lowest ID if none have RequestTree TRUE • MUST comply with the decision of Rn to be the root of a distribution tree • Pseudonodes (shared links) MUST set RequestTree = FALSE 68th IETF - Prague

  10. Miscellaneous • Added some pseudo-code for forwarding behavior • Removed duplications in the text • Fixed other minor issues 68th IETF - Prague

  11. Added Algorhyme V2 • 1.1. Algorhyme V2 I hope that we shall one day see A graph more lovely than a tree. A graph to boost efficiency While still configuration-free. A network where RBridges can Route packets to their target LAN. The paths they find, to our elation, Are least cost paths to destination! With packet hop counts we now see, The network need not be loop-free! RBridges work transparently. Without a common spanning tree. Ray Perlner 68th IETF - Prague

More Related