Changes between Initial Version and Version 1 of ConnectivityGuidelines

Timestamp:

06/21/10 12:37:48 (14 years ago)

Author:

jwilliams@bbn.com

Comment:

--

ConnectivityGuidelines

@@ +1 @@
+'''This page is a pre-draft. The content here will change significantly'''
+[[PageOutline]]
+= Summary =
+In order for two sites to communicate they need some help from every service provider along the network path between the sites. The service providers involved may include: campus IT, regional providers, national research backbones.
+
+Decide which methods your campus can use to connect with other campuses.  View what various Campuses have to offer (FIXME - campus index) here.  While your establishing connectivity for your campus if you regard the info on your campuses page then other campuses can also see what you are available.
+
+See CampusConnectivityOverview for more information on various options. See GeniConnectivity for a matrix of potential options that various campuses support. This will involve determining what types of support you Once you know which connection method you'd like to use
+
+Every campus's situation is unique. This is a general common case guideline. Your campus's particular paths and goals may deviate from this outline. 
+
+Note that it's assumed that all of this VLAN provisioning is discussing 801.q tagged (aka trunked) VLANs. This is typically the case.
+
+= Layer 2 connections =
+==  Backbone Options ==
+This is a high-level summary page, see the corresponding Backbone page for more information.
+If you and your partner campus have accessibility to the same backbone network you have several choices.
+
+This section lays out the general procedure for establishing an end-to-end connection over a backbone network.
+
+== Backbones ==
+NLR-LINK FIXME
+I2-LINK. FIXME
+
+== Once per backbone ==
+
+ 1. Join the Backbone service (contracts, negotiations, bartering, etc). 
+
+ If this is your campus's first time connecting to a backbone you'll need to establish a relationship with your backbone and establish a backbone endpoint.  There may already be arrangements for your Regional Provider to share/provide access to a Backbone. 
+
+ 2. Obtain an account for provisioning connections in the backbone network. Strictly speaking this isn't always necessary if your partner campus has access - they can provision the VLAN.
+
+3. Determine the name of your endpoint. 
+
+== Once per campus ==
+You may be required to grant permissions to your partner campus to connect to your backbone endpoint This is the case For NLR (FIXME - link to NLR)
+
+== Once per path ==
+These section outlines the steps necessary for your campus to get connectivity to your backbone endpoint. Your partner campus will also need to do these steps, though they may have established extra connections that are available. Note that you'll need a unique VLAN per unique connection you want to establish. If you wish to connect to multiple campuses, you'll need to provision multiple VLANs.  
+
+=== Regional provisioning ===
+ Your campus will need to request your regional to provision quest VLANs from your retie reach from your campus's site endpoint (FIX NAME). If you plan on connecting to multiple campuses, or have multiple unique connections to a campus,  you may want to request multiple VLANs.
+
+=== your campus ===
+Now that you know which VLAN(s) are available in the regional network to reach your campus's backbone endpoint,  you'll need to provision the same VLAN IDs from your campus's regional endpoint to  the particular network gear that you wish to share. 
+
+Your partner campus will need to provision VLAN(s) to their endpoint as well.
+
+=== backbone ===
+Now that both your campus and your partner campus have VLANs provisioned to your corresponding endpoints, you can, finally, provision the VLAN in the backbone to connect the endpoints into one network. You, or your partner campus, can perform this action via the backbone's web provisoning service.
+
+
+== Notes and Gotchas ==
+ * NLR's web provisioning service (Sherpa) does provide VLAN translation; your campus, your partner campus, and all regionals will need to provision ''the same VLAN ID'' to establish a connection. NLR may be able to provide translation on a case-by-case basis. If this is required you will need to connect NLR directly. (FIXME - add link to VLAN translation)
+
+== Simular regional ==
+Sometimes campuses share the same regional. It's possible that the regional can provide a direct layer 2 connection between your campus's regional endpoint and your partner campus's regional endpoint.  You campus and your regional campus can then provision a VLAN within the campus and regional network as outlined above. IN FIXME. You'll need to discuss with your regional whether your campus and your partner campus need to negotiate the same VLAN ID.
+
+== Testing ==
+Typically both campuses will assign IP addresses to various hosts to allow common IP-based programs to quickly verify Layer-2 connectivity.
+ 
+You'll talk with you partner campus to decide on a IP subnet that can be used on both campuses. You'll then want to provide you're partner campus.
+
+''''TIP''' if you're the first person to start IP negotiations specify what IP address you want to use. Such as  "I plan on using 10.37.45.12 -  what do you plan on using". This may help prevent the case where both campuses use the same IP address.
+
+== VLAN ID conflicts ==
+Given the limited number of VLAN IDs, it's conceivable to run into a conflict when provisioning a common VLAN between two end points. Here are a few common options to resolve the conflict.
+
+=== QinQ ===
+
+QinQ is a tunneling option which "wraps" your frames from marked with your VLAN ID within another VLAN ID. For example, your can provision VLAN 1234 within NLR and your network, but your regional is already using this VLAN iD. YOur regional can assign you another VLAN ID say 2345, for this connection and tunnel VLAN ID 1234 through this connection so that you can Reach NLR with your VLAN iD intact.
+  
+=== VLAN translation ===
+ VLAN translation translates one VLAN ID to another allowing two separate VLAN ID's to coexist as if it was one VLAN topology. Internet2's ION interface allows for translation. This means that your campus only needs to provision a VLAN ID trough your campus and regional network to your ION endpoint. Your partner campus does the same without the requirement to use the same VLAN ID as your campus. once both campuses can reach there ION endpoints ION will translate your campus VLAN ID to your partner campuses ID, and vice versa, to establish the connection.
+
+= Layer 3 connections =
+
+If your campus doesn't have layer 2 connectivity (no backbones, must go through a router, etc) then layer 3 connectivity may be an option. For GENI experiments this requires tunnel
+
+
+== connections ==
+ backbone:: 
+   Your campus may have access to a backbone Layer3 connection such as  !PackeNet.
+
+ commodity internet::
+  You use the normal "commodity" internet path's through your ISP(s).
+
+== tunneling options ==
+ GRE::
+   FIXME describe GRE here.
+ Software Encapsulation::
+   FIXME mention Capsulator.
+ MPLS::
+   FIXME describe MPLS Here
+
+{{{
+#!comment
+Please don't edit below this line - Thanks!
+}}}
+----
+ * SiteIndex
+ * GeniConnectivity
+ * Questions?
+{{{
+#!html
+<a href="mailto:help@geni.net?subject=[GENI site] ConnectivityGuidelines question">Email us</a> with questions and feedback on this page!
+}}}
+
+