Internet DRAFT - draft-nalawade-softwire-mesh-encap-attribute
draft-nalawade-softwire-mesh-encap-attribute
Internet Draft June 2006
Internet Draft Gargi Nalawade
June 2006 Simon Barber
David Ward
Ruchi Kapoor
Chris Metz
Cisco Systems
BGPv4 Softwire Mesh Encapsulation Attribute
draft-nalawade-softwire-mesh-encap-attribute-
00.txt
1. 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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
draft-nalawade-softwire-mesh-encap-attribute-00.txt [Page 1]
Internet Draft - 2 - June 2006
http://www.ietf.org/shadow.html.
2. Abstract
[SW-MESH-FMWK] provides a generalized framework to connect islands of
various network layer protocols over a backbone network composed of
same or different network layer protocol routers. To this end,
packets sourced from the islands are forwarded over a signaled
softwire in the backbone network by encapsulating the packets in a
softwire transport header. This document define a new BGP attribute
called the "Softwire Mesh Encasulation attribute" that are advertised
by the softwire mesh endpoints to build these transport headers.
3. Introduction
This document defines a new BGP attribute called the Softwire Mesh
Encapsulation Attribute which will be used to carry Softwire Mesh
endpoint information with BGP updates.
4. Format of the Softwire Mesh Encapsulation Attribute
The format of the BGP Softwire Mesh Encapsulation attribute will be
as follows:
| Attr. Flags | Attr.Type Code|
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|1|0|?|UNUSED | Type = TBD | Length (2 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Attribute Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BGP Softwire Mesh Encapsulation Attribute is a variable length,
optional transitive attribute. The Value field of the attribute
contains one or more Tunnel Encapsulation TLVs. The Value field of
the Softwire Mesh Encapsulation Attribute is encoded as follows and
may contain one or more tuples of the following:
- Type Field : 2 octets
draft-nalawade-softwire-mesh-encap-attribute-00.txt [Page 2]
Internet Draft - 3 - June 2006
- Length Field: 2 octets
- Value Field : Variable
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload AFI | Payload SAFI | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The Type field identifies the type of the Tunnel Eg. mGRE or
IPSEC. The format of the Type Field is as shown below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T - Transitive bit
If the 'T' bit has a value of 1, it implies that the Tunnel type is
transitive across ASes. If the 'T' bit has a value of 0, it implies
that the Tunnel type is non-transitive across ASes.
Remaining 15 bits: Indicate the type of the TLV.
Length: The Length is 2 octets long and indicates the length of the
Value field.
Value: The Value fields for all Encapsulation TLVs, will carry the
following fields :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | |
+-+-+-+-+-+-+-+-+ +
| Tunnel Encapsulation |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-nalawade-softwire-mesh-encap-attribute-00.txt [Page 3]
Internet Draft - 4 - June 2006
where
Preference - Preference is a 2 Octet field containing a Preference
associated with the TLV. The Preference value indicates a preferred
ordering of tunneling encapsulations according to the sender (i.e.
egress PE). The recipient of the information SHOULD take the
sender's preference into account in selecting which encapsulation it
will use. A higher value indicates a higher preference.
Flags - Flags is a 1 Octet field containing flag-bits.
Tunnel Encapsulation: The Tunnel Encapsulation field will carry the
tunnel encapsulation information, specific for this particular tunnel
'Type'.
The Value field will have a fixed part and an optional variable part
as specified by the respective Tunnel Types. The variable part when
present will contain Sub-TLVs encoded as follows :
- Sub-Type Field: 1 octets
- Length Field : 1 octets
- Value Field : Variable
5. Operation
A BGP speaker that supports the Softwire Mesh Encapsulation
Attribute, MUST accept all Encapsulation TLV types. If the
Encapsulation TLV is transitive, The BGP speaker MUST forward it even
if it does not understand it. This attribute MUST only be carried
with the BGP Tunnel SAFI [BGP-TUN-SAFI].
If this attribute is carried with another BGP SAFI, the receiving BGP
Speaker MUST ignore this attribute.
A Capability has not been defined for this attribute intentionally.
The presence of the Tunnel SAFI implies the Capability to understand
this Softwire Mesh Encapsulation attribute.
6. Deployment Examples
The Softwire mesh solution could be used for establishing Tunnels
across an IPv6 backbone to carry IPv4 or other traffic. In this case,
the tunnels will be established between AFBRs. AFBRs would negotiate
Capabilities for the Tunnel safi.
Example of the tunnel safi sent out from an egress AFBR would be:
draft-nalawade-softwire-mesh-encap-attribute-00.txt [Page 4]
Internet Draft - 5 - June 2006
{Tunnel AFI/SAFI = 2/64} {Softwire Mesh Encapsulation Attribute = 42,
"IPv4 is payload, IPv6 is transport"} {Tunnel Encap Attribute (1) =
GRE, preference=99} {Tunnel Encap Attribute (2) = L2TPv3,
preference=50} {NLRI = ID: FE80::77}
In this example the egress AFBR is telling all the ingress AFBRs that
it can handle IPv4 payloads carried by GRE and L2TPv3 IPv6 softwire
transport tunnels with a preference for the GRE tunnel.
Next AFBR-2 adverts IPv4 AF/SAFs with the Softwire Nexthop Attribute
of:
{Softwire Nexthop Attribute = 42: FE80::77}
The Softwire Nexthop attribute points to softwire mesh Encapsulation
attribute = 42. This tells the ingress AFBR that to reach the
advertised IPv4 AF/SAF prefixes use the highest preference active
tunnel in tunnel group 42 which is the GRE tunnel with preference =
99.
7. Security Considerations
This extension to BGP does not change the underlying security issues.
8. Acknowledgements
The authors would like to thank Eric Rosen, Christian Cassar Pradosh
Mohapatra and Scott Wainner for their feedback, review and comments.
9. Normative References
[BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol
4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-26.txt, April 2005.
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.
[BGP-TUN] Kapoor, R., Nalawade, G., Appanna, C., "BGPv4 Tunnel
Encapsulation Attribute", In Progress.
[SW-MESH-FMWK] Metz, C. et al, "A Framework for Softwire Mesh
Signaling, Routing and Encapsulation across IPv4 and IPv6 Backbone
Networks", draft-wu-softwire-mesh-framework-00, June 2006.
draft-nalawade-softwire-mesh-encap-attribute-00.txt [Page 5]
Internet Draft - 6 - June 2006
10. Author's Addresses
Gargi Nalawade
170 Tasman Drive
San Jose, CA, 95134
cisco.com
David Ward
408 St Peter Street, Hamm Bldg
St Paul, MN, 55102
cisco.com
Simon Barber
Cisco Systems, Inc
cisco.com
Ruchi Kapoor
170 Tasman Drive
San Jose, CA, 95134
cisco.com
Chris Metz
170 Tasman Drive
San Jose, CA, 95134
cisco.com
11. Intellectual Property Statement
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 implementors or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
draft-nalawade-softwire-mesh-encap-attribute-00.txt [Page 6]
Internet Draft - 7 - June 2006
Director.
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
ietf-ipr@ietf.org.
12. Full Copyright Statement
"Copyright (C) The Internet Society (2006).
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."
Additional copyright notices are not permitted in IETF Documents
except in the case where such document is the product of a joint
development effort between the IETF and another standards development
organization or the document is a republication of the work of
another standards organization. Such exceptions must be approved on
an individual basis by the IAB.
"This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
13. Expiration Date
This memo is filed as <draft-nalawade-softwire-mesh-encap-attribute-00.txt>
expires December, 2006.
draft-nalawade-softwire-mesh-encap-attribute-00.txt [Page 7]
