Browse Prior Art Database

The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute (RFC5512)

IP.com Disclosure Number: IPCOM000181732D
Original Publication Date: 2009-Apr-01
Included in the Prior Art Database: 2009-Apr-10
Document File: 14 page(s) / 31K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Mohapatra: AUTHOR [+2]

Abstract

In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 9% of the total text.

Network Working Group                                       P. Mohapatra Request for Comments: 5512                                      E. Rosen Category: Standards Track                            Cisco Systems, Inc.                                                               April 2009

    The BGP Encapsulation Subsequent Address Family Identifier (SAFI)                and the BGP Tunnel Encapsulation Attribute

Status of This Memo

   This document specifies an Internet standards track protocol for the    Internet community, and requests discussion and suggestions for    improvements.  Please refer to the current edition of the "Internet    Official Protocol Standards" (STD 1) for the standardization state    and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the    document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal    Provisions Relating to IETF Documents in effect on the date of    publication of this document (http://trustee.ietf.org/license-info).    Please review these documents carefully, as they describe your rights    and restrictions with respect to this document.

Abstract

   In certain situations, transporting a packet from one Border Gateway    Protocol (BGP) speaker to another (the BGP next hop) requires that    the packet be encapsulated by the first BGP speaker and decapsulated    by the second.  To support these situations, there needs to be some    agreement between the two BGP speakers with regard to the    "encapsulation information", i.e., the format of the encapsulation    header as well as the contents of various fields of the header.

   The encapsulation information need not be signaled for all    encapsulation types.  In cases where signaling is required (such as    Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing    Encapsulation (GRE) with key), this document specifies a method by    which BGP speakers can signal encapsulation information to each    other.  The signaling is done by sending BGP updates using the    Encapsulation Subsequent Address Family Identifier (SAFI) and the    IPv4 or IPv6 Address Family Identifier (AFI).  In cases where no    encapsulation information needs to be signaled (such as GRE without

 Mohapatra & Rosen           Standards Track                     [Page 1]
 RFC 5512    BGP Encapsulation SAFI and Tunnel Encapsulation   April 2009

    key), this document specifies a BGP extended community that can be    attached to BGP UPDATE messages that carry payload prefixes...