<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

  <!ENTITY rfc2119 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc2629 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
  <!ENTITY rfc6325 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6325.xml'>
  <!ENTITY rfc6326 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6326.xml'>
  <!ENTITY rfc6327 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6327.xml'>
<!ENTITY I-D.draft-hasmit-otv-03 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hasmit-otv-03.xml">    
]>


<!-- see note under "mailing list" -->


<?rfc compact='yes'?>
<?rfc toc='yes'?>
<!-- Validator on -->
<?rfc strict="yes" ?>

<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>

<!-- RFC references as names, not numbers -->
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>

<rfc ipr="trust200902" docName="draft-xl-trill-over-wan-01.txt"
    category="std" >
<!-- ipr: full2026 / noDerivativeWorks2026 / none -->

<front>
<title abbrev="Extending TRILL over WAN">
   Extending TRILL over WAN
</title>


<author fullname="Xiaolan Wan"  initials="X" surname="Wan">
      <organization>HangZhou H3C Co. Limited</organization>
      <address>
         <postal>
            <street>No. 2 ChuangYe Road, HaiDian District</street>
            <city>Beijing</city>
           <country>P.R. China</country>                       
           </postal>
         <phone>+86 10 82774971 </phone>
         <email>wxlan@h3c.com</email>
      </address>
  </author>

  <author fullname="Xiaopeng Yang"  initials="X" surname="Yang">
      <organization>HangZhou H3C Co. Limited</organization>
      <address>
         <postal>
            <street>No. 2 ChuangYe Road, HaiDian District</street>
            <city>Beijing</city>
           <country>P.R. China</country> 
           </postal>
         <phone>+86 10 82774963 </phone>
         <email>yxp@h3c.com</email>
      </address>
  </author>
  
<author fullname="Vishwas Manral"  initials="V" surname="Manral">
      <organization>Hewlett-Packard Co.</organization>
      <address>
         <postal>
            <street>19111 Pruneridge Ave.</street>
            <city>Cupertino</city>
            <region>CA</region>
          <country>USA</country>
           </postal>
         <email>vishwas.manral@hp.com</email>
      </address>
  </author> 
 
 <author fullname="Alvaro Retana" initials="A" surname="Retana" >
      <organization>Hewlett-Packard Co.</organization>
      <address>
         <postal>
            <street>2610 Wycliff Road</street>
            <city>Raleigh</city>
            <region>NC</region>      
          <country>USA</country>
           </postal>
         <email>alvaro.retana@hp.com</email>
      </address>
  </author>     

<date month="June" day="8" year="2012" />
<!-- <area ...>, <workgroup ...>, <keyword ...>, <keyword ...> <note..> -->

<abstract>
<t>
TRILL is a key technology for large-scale layer 2 networking 
within a data center, TRILL over WAN_(ToW) provides a scalable
 and simple solution that interconnect multiple TRILL networks to form a
single TRILL domain using the currently deployed enterprise or service 
provider networks. This document provides an overview of this
solution.  
</t>
</abstract>

</front>

<middle>

<section title="Overview" anchor="overv">
<t>
TRILL over WAN is a technology for supporting L2 VPNs over an L2/L3 
infrastructure. It provides an "over-the-top" method of doing 
virtualization among several sites where the routing and forwarding 
state is maintained at the network edge, but not within the site or 
in the core.
<vspace blankLines="1"/>
TRILL over WAN can reside in a small number of device at the edge 
between TRILL sites and the core,  we call these devices "Joint Devices" 
which perform typical transit Rbridges functions(nickname-based forwarding) 
and perform overlay functions on their core facing interfaces. 
<vspace blankLines="1"/>
TRILL traffic which requires traversing the WAN to reach its destination, 
is prepended with an IP header. As shown in figure1, if a destination 
RBridge(Nickname) is reachable via Joint Device S2(with a core facing IP 
address of IPB), other Joint Devices forwarding traffic to such Rbridge 
will add on IP header with a destination IP address of IPB and forward 
the traffic into the core. The core will forward traffic based on IP 
address IPB, once the traffic makes it to Joint Device S2 it will be 
stripped of the overlay IP header and it will be forwarded into the 
site in the same way a regular RBridge would forward a packet.  
Broadcast or multicast traffic is encapsulated with a multicast header 
and follows a similar process.
<vspace blankLines="1"/>
<figure anchor="intraFigure" align="center" title="Traffic encapsulation"><artwork><![CDATA[

+---+     +---+IPA  --------- IPB +---+     +---+           
|S10|-----|S1 |----/ IP Core \----|S2 |-----|S20|      
+---+  ^  +---+    \ Network /    +---+  ^  +---+        
       |            ---------            |          
       |                                 |
       |           +------------+        |
       |           |   DA=IPB   |        |
       |           +------------+        |
       |           |   SA=IPA   |        |
 +------------+    +------------+    +------------+
 |Outer Eth.  |    |Outer Eth.  |    |Outer Eth.  |
 |Header      |    |Header      |    |Header      |
 +------------+    +------------+    +------------+ 
 |TRILL Header|    |TRILL Header|    |TRILL Header|                     
 +------------+    +------------+    +------------+                          
 |Inner Eth.  |    |Inner Eth.  |    |Inner Eth.  |                 
 |Frame       |    |Frame       |    |Frame       |
 +------------+    +------------+    +------------+        
                                                               
]]></artwork></figure>

<vspace blankLines="1"/>
The key piece that TRILL over WAN adds is the state to map a 
given egress Nickname to an IP address of the Joint Device 
behind which that egress Nickname is located. TRILL over WAN 
forwarding is a function of mapping a destination Nickname 
to a Joint Device IP address in the overlay network.
<vspace blankLines="1"/>
To achieve this, a control plane is required to exchange 
the reachability information among different Joint Devices. 
After Joint Device discovery and adjacency setup, the virtual 
links to neighbor Joint Devices will be treated as TRILL 
interface, and the TRILL's control plane runs over these 
virtual links. Through these steps, all the Rbridges in multiple 
site forms a single TRILL domain. Each Rbridge (including Joint 
Device) calculates its TRILL forwarding table independently.
Figure 2 shows what the resulting forwarding tables look like in 
a simple example.
<vspace blankLines="1"/>
<figure anchor="interFigure" align="center" title="Forwarding Tables"><artwork><![CDATA[

+---+ L11+---+IPA  --------- IPB +---+ L21+---+   
|S10|----|S1 |----/ IP Core \----| S2|----|S20|   
+---+    +---+    \ Network /    +---+    +---+   
                   ---------                     
                                                
                                                
S1                        S2                    
+----------------------+  +-------------------+ 
|Nickname   |Interface |  |Nickname |Interface| 
+----------------------+  +-------------------+ 
|   S10     |   L11    |  | S10     |  IPA    | 
+----------------------+  +-------------------+ 
|   S20     |   IPB    |  | S20     |  L21    | 
+----------------------+  +-------------------+ 
|   S1      |   self   |  | S1      |  IPA    | 
+----------------------+  +-------------------+ 
|   S2      |   IPB    |  | S2      |  self   | 
+----------------------+  +-------------------+ 

]]></artwork></figure>

<vspace blankLines="1"/>
TRILL over WAN supports multi-homing for sites where one 
or more of the Joint Devices connected to core network. 
It can support active-active multi-homing capability and 
loop elimination by nature of TRILL. No need to add other 
extra mechanism.

</t>
</section>


<section title="Terminology">   
		<t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119 <xref target="RFC2119"/>.
   </t> 

   <t>
   <cref>NOTE TO RFC EDITOR:  Please remove the following text
   before publication.</cref>  <vspace/>
   Some ideas of this specification is being discussed on the EAI mailing list.  See
   https://www1.ietf.org/mailman/listinfo/ima
   for information about subscribing. The list's archive is at
   http://www1.ietf.org/mail-archive/web/ima/index.html.
   </t>
   
</section>


<section title="Control Plane" anchor="CtrlPlane">
<section title="Provider Control Plane">
<t>
The provider control plane enables unicast reachability among the 
Joint Devices and also provides the multicast group than makes Joint 
Devices adjacent from the overlay control plane perspective. It also 
provides the multicast trees in the core that will be used for 
optimal forwarding of the TRILL data traffic.
</t>
</section>

<section title="Overlay Control Plane">
<t>
The overlay control plane provides auto-discovery of the 
Joint Devices that are members of an overlay VPN. 
<vspace blankLines="1"/>
The TRILL control plane traffic between Joint Devices of 
different sites will be carried over the virtual link. 
<vspace blankLines="1"/>
Detailed to be added.
</t>



<section title="Edge Device Discovery and Adjacency setup">
<t>

See draft-hasmit-otv-03 2.2.1.
<vspace blankLines="1"/>

</t>
</section>



<section title="Control Plane Packet Encapsulation and Relay">
<t>
Any Jonit Device of the site is virtual link with the other Jonit Devices 
of the other sites. Any Jonit Device should encapsulate the ISIS routing
information of its site, and then relay it to the other Joint Devices of the other sites. 
<vspace blankLines="1"/>
There is no different between the virtual links and the physical links to the TRILL protocol.
The TRILL protocol calculates the routing information among the whole TRILL domain.

<vspace blankLines="1"/>

</t>
</section>

</section>


</section>

<section title="Data Plane" anchor="data-pl">
<section title="Encapsulation">
<t>
The encapsulation format is TRILL frame encapsulated in 
UDP inside of IPv4 or IPv6.
<vspace blankLines="1"/>
The format of the UDP IPv4 encapsulation is as follows:
<figure>
	  <artwork> 
	    <![CDATA[ 
                    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live | Protocol = 17 |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Source-site TRILL Joint Device IP Address      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Destination-site TRILL Joint Device (or multicast) Address  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Source Port = xxxx        |         Dest Port = TBD       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           UDP length          |        UDP Checksum = 0       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|R|           Overlay ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Instance ID                          | Reserved      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Outer Ethernet Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|                      TRILL Header                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      
|                 Inner Ethernet Header                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Ethernet Payload                           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
               ]]> 
	  </artwork>
	</figure>      
<vspace blankLines="1"/>	
The format of the UDP IPv6 encapsulation is as follows:
<figure>
  <artwork>
   <![CDATA[
                    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        | Next Header=17|   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+              Source-site TRILL Joint Device IPv6 Address      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+   Destination-site TRILL Joint Device (or multicast) Address  +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Source Port = xxxx      |       Dest Port = TBD         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           UDP Length          |        UDP Checksum           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|R|           Overlay ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Instance ID                          | Reserved      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Outer Ethernet Header                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|                        TRILL Header                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Inner Ethernet Header                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Ethernet Payload                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	  ]]>
	  </artwork>
	</figure>
<vspace blankLines="1"/>	

</t>

</section>
<section title="Forwarding Process">
<section title="Forwarding from an Internal Link to the Overlay">
<t>
The forwarding within a site is normal TRILL forwarding, 
so here only describes the forwarding from an Internal link to 
the Overlay Link, or vice versa.
<vspace blankLines="1"/>
A Joint Device is a transit Rbridge from TRILL point of view. 
When a TRILL packet is received from the internal interface, 
egress Nickname is used to lookup the Nickname table which will 
yield a next-hop IP address entry pointing to a remote Joint 
Device. Then the packet is encapsulated with UDP/IP header and 
sent over the overlay interface to destination Joint Device 
at Layer-3 as a regular IP packet.
</t>

</section>

<section title="Forwarding from the Overlay Link to an Internal Link">
<t>
When a packet is received on the overlay interface, it will be IP 
decapsulated to reveal the inner TRILL(including the outer MAC) 
header for forwarding. The egress Nickname will used for forwarding, 
the forwarding action is same as a transit RBridge.
</t>
</section>

<section title="Multicast Packet Flows">
<t>
To be added.
</t>
</section>

<section title="Broadcast Packet Flows">
<t>
To be added.
</t>
</section>

<section title="Mac Address Learning">
<t>
The TRILL edge devices learn remote MAC addresses(including the MAC 
addresses in other data centers) in data plane by hardware. In most cases, 
the Joint device is like a transit RBridge, and doesn't learn end host's 
MAC addresses. From DCI(Data Center Interconnect) perspective, the Joint 
Device is DCI device at the same time, so TRILL over WAN can relieve the 
pressure of MAC addresses table capability in DCI device. 
</t>
</section>

<section title="Multi-homing">
<t>
In the situation of multi-homing shown as Figure 3, all the Joint Devices 
can be active by the nature of TRILL.
<vspace blankLines="1"/>
Figure 4 shows what the resulting forwarding tables would look like in 
the multi-homing example.
<vspace blankLines="1"/>
<figure anchor="eepIntra" align="center" title="Multi-homing Scenario"><artwork><![CDATA[

 +---+ L1 +---+ IPA      --------       IPD +---+    +---+        
 |S10|----| S1|-------- /        \ ---------|S4 |----|S21|       
 +---+    +---+        /          \         +---+    +---+
       \/L2           |   IP Core  |              \/
       /\             |   Networ   |              /\
 +---+    +---+ IPB    \          /     IPC +---+    +---+
 |S11|----|S2 |-------- \        / ---------|S3 |----|S20|
 +---+    +---+          --------           +---+    +---+

]]></artwork></figure>
<vspace blankLines="1"/>

<figure anchor="eepInter" align="center" title="Forwarding Table of S1">
  <artwork>
  <![CDATA[
 S1                                             
+----------------------+                        
|Nickname   |Interface |                        
+----------------------+                        
|   S1      |   self   |                        
+----------------------+                        
|   S2      |   -      |                        
+----------------------+                        
|   S3      |   IPC    |                        
+----------------------+                        
|   S4      |   IPD    |                        
+----------------------+                        
|   S10     |   L1     |                        
+----------------------+                        
|   S11     |   L2     |                        
+----------------------+                        
|   S20     | IPC/IPD  |                        
+----------------------+                        
|   S21     | IPC/IPD  |                        
+----------------------+                        

  ]]>
  </artwork>
  </figure>
<vspace blankLines="1"/>
In S1 device, the traffic destinated to S10 and S21 have two next hops, IPC 
and IPD. In forwarding process, hashing of TRILL packet inner information 
will be used to determine which next hop IP address to use. Thus, the 
ingress traffic will be load balanced between multiple Joint Devices 
within a site.

</t>
</section>

</section>


</section>


<section title="IANA Considerations">
<t>
	IANA need to allocate the following UDP Ports for the TRILL IS-IS
	and Data channels:
      </t>
      <figure>
	<artwork> 
	  <![CDATA[ 
       UDP Port           Protocol

        TBD              TRILL IS-IS Channel           
        TBD              TRILL Data Channel
          ]]> 
	</artwork>
      </figure>
      <t>
</t>

</section>


<section title="Security Considerations" anchor="security">
<section title="Failure Separation">
<t>
To be added.
</t>
</section>
</section>


<section title="Acknowledgements">
<t>
Much of the wording herein was adapted from draft-hasmit-otv-03.

</t>
</section>


</middle>


 <back>
    <references title="Normative References">
      &rfc2119;
      &rfc6325;
      &rfc6326;
      &rfc6327;
      &I-D.draft-hasmit-otv-03;
    </references>
      
  </back>

</rfc>

