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 expires December, 2006. draft-nalawade-softwire-mesh-encap-attribute-00.txt [Page 7]