[rbridge] Updated charter
touch at ISI.EDU (Joe Touch) Wed, 02 February 2005 10:56 UTC
From: "touch at ISI.EDU"
Date: Wed, 02 Feb 2005 10:56:52 +0000
Subject: [rbridge] Updated charter
In-Reply-To: <200502021844.BBO48908@mira-sjc5-f.cisco.com>
References: <200502021844.BBO48908@mira-sjc5-f.cisco.com>
Message-ID: <4201222D.5000809@isi.edu>
X-Date: Wed Feb 2 10:56:52 2005
Michael Smith wrote: ... > Yes, I was referring to traditional translational bridges which "adapt" the > headers. AFAIK, a bridge either retains the MAC header (transparent > bridging), translates the MAC header (translational bridging), strips the > header and terminates the frame (i.e. BPDUs), or encapsulates/decapsulates > it when transporting across specific media types. I was assuming that > "replace the MAC header" in this context was referring to translational > bridging. If not, it would be nice to see a specific example as to what is > meant by "replace" and if it implies something beyond the capabilities just > stated. Sure - translating 802 token ring to 802 ethernet is easy. IMO, they're effectively a single L2 by design. Translating 802 to ATM is not. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/rbridge/attachments/20050202/bf9aac7d/signature.bin From fltemplin at acm.org Wed Feb 2 11:04:22 2005 From: fltemplin at acm.org (Fred L. Templin) Date: Wed Feb 2 11:04:37 2005 Subject: [rbridge] An IPvLX Study In-Reply-To: <62173B970AE0A044AED8723C3BCF238105CD4445@ma19exm01.e6.bcs.mot.com> Message-ID: <003201c5095a$01ae6480$6401a8c0@grayling> Joe Touch and I have been discussing off-list about a study I have been involved with over the past few years which has resulted in the following two Internet-Drafts: http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-05.txt and an updated version that will obsolete both of these at: http://ipvlx.com/IPVLX.txt The study proposes mechanisms and operational practices for establishing virtual links between IP peer end nodes. The virtual link can provide authentication (e.g., using Secure Neighbor Discovery - SEND) and confidentiality (e.g., using IPSec). In some cases, the virtual link can be extended all the way to the end nodes but in other cases it may be desireable to terminate the link at a router in the end node's network, e.g., to protect people and assets from would-be attackers. (Both alternatives are supported in the model proposed by the study.) The study proposes IPv6 as the L3 protocol for end-node addressing and IPv4 as the L2 protocol, i.e., IPv6-in-IPv4 tunneling, but it could easily be extended to deal generically with IP-in-IP tunneling (where "IP" could refer to any IP version). The study proposes special nodes called: "IPvLX Gateways" that get involved in establishing and providing transit switching for virtual links. These nodes exhibit some of the same hybrid routing/bridging features proposed for Rbridges, and can be deployed incrementally without requiring flag-day upgrades of existing routers and bridges. In fact, IPvLX gateways need only be deployed in the same locations that an IPv4 NAT would be deployed. While the study presents a big-picture proposal for a next-generation Internet architecture, it is also useful to consider the component aspects seperately. In particular: 1) Autoconfiguration - IPvLX nodes automatically configure themselves for operation with zero configuration. 2) Encapsulation - the study proposes a special encapsulation in the L2 (IPv4) header to encode flow identification information. 3) Link adaptation - the study proposes a link adaptation scheme used by virtual link endpoints to dynamically determine the best-fit L2 segment size (without packet loss) while presenting a uniform MTU to L3. 4) Virtual link extension - the study proposes methods for establishing virtual links through Secure Neighbor Discovery and establishing soft state for flow switching in intermediate IPvLX gateways. 5) Error handling - a method for relaying ICMPv4 error messages back to the IPvLX gateway at the near-end of a virtual link is proposed. 6) Mobilitiy - aspects of IPvLX node mobility are discussed. Although this study is now concluded, it is my sincere hope that some/all of its aspects may be found useful for adoption as work items for this group and that others will be interested in helping to carry the work forward. Please send any questions/comments, Fred L. Templin American Kestrel Consulting fltemplin@acm.org
- [rbridge] Updated charter Erik Nordmark
- [rbridge] Updated charter Pekka Savola
- [rbridge] Updated charter Bill Sommerfeld
- [rbridge] Updated charter Erik Nordmark
- [rbridge] Updated charter Bill Sommerfeld
- [rbridge] Updated charter Bill Sommerfeld
- [rbridge] Updated charter Michael Smith
- [rbridge] Updated charter Michael Smith
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Fred L. Templin
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Joe Touch
- [rbridge] Updated charter Erik Nordmark
- [rbridge] Updated charter Joe Touch
- [rbridge] updated BOF website Joe Touch
- [rbridge] Updated charter Erik Nordmark
- Re: [rbridge] Updated charter Ralph Droms
- Re: [rbridge] Updated charter Joe Touch
- Re: [rbridge] Updated charter Linda Dunbar
- Re: [rbridge] Updated charter James Carlson
- Re: [rbridge] Updated charter Linda Dunbar
- Re: [rbridge] Updated charter James Carlson
- Re: [rbridge] Updated charter Linda Dunbar
- Re: [rbridge] Updated charter James Carlson
- Re: [rbridge] Updated charter Eric Gray