1 / 11

LHCONE “Point-to-Point Connection Service” Service Definition

LHCONE “Point-to-Point Connection Service” Service Definition. Jerry Sobieski. The Service Definition. Specifies technically what the user experiences due to the service Specifies ancillary processes and procedures that will be available and/or followed to support the service

karl
Télécharger la présentation

LHCONE “Point-to-Point Connection Service” Service Definition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LHCONE “Point-to-Point Connection Service”Service Definition Jerry Sobieski

  2. The Service Definition • Specifies technically what the user experiences due to the service • Specifies ancillary processes and procedures that will be available and/or followed to support the service • Intended to provide the LHCONE community with service guarantees *and* ability to interoperate with non-LHC infrastructure

  3. Technical description • The LHCONE point to point Connection Service - “P2PCS” - will: • Deliver performance guaranteed point-to-point connections on a global basis for the LHCONE community • Provides a single contiguous service region with a global service reach. • The global service region is the result of numerous autonomous network service domains and open exchange points inter-connecting to provide a single consistent end-to-end P2PCS capability. • The service employs open and standardized protocols to deliver these capabilities.

  4. Connection Instance • P2PCS Connections are Point to Point only (initially) • P2PCS payload is IEEE 802.1Q frames. • The service can deliver frames between ethernet endpoints associated with different VLANs • Payload frames are delivered end to end unmodified, with two explicit exceptions: • VLAN tags may be re-written (which means the FCS field will need be re-computed as well.) • Inter-arrival time of frames associated with a particular Connection is not preserved end to end (i.e. no jitter control is provided.) • P2PCS Connection Endpoints are individually identified by the full topological specifications that uniquely identify the flow to be carried end to end • Ex: <networkid>…<switchid><bladeid><portid><VLANid> • P2PCS connections are not VLANs – they are pipes that carry payload datagrams formatted in a particular fashion. • This allows us to deliver ethernet frames without requiring the intermediate network transport infrastructure to be ethernet equipment.

  5. Reservation Parameters • Origination STP* • Destination STP* • Capacity* – Megabits per second • Max Payload datagram size – MTU • default MTU 9100 bytes • Shaping parameters • Max Burst size • Burst window • Schedule* – start & end time/date • Authorization credentials* • (*) indicates a required user specified parameter • Other parameters may be allowed to default

  6. Scheduling • P2PCS Connections can be scheduled in advance • They may also be immediate (“now”) • They all have a start and end time/date • The service supports the following functions: • Reserve/Cancel • Provision/Release • Query • All such functions are will be individually authorized against credentials provided by the requesting agent • Security and privacy is a primary concern for global services – particularly where resources may be acquired from or by outside agents

  7. Scheduling • Scheduling is sacrosanct. • Once confirmed, a reservation will not be removed or overridden except to insure the health of the system itself. • Failure by the service provider to deliver a confirmed connection – for any reason - constitutes a “critical outage”. • In general… • These connections are not “protected” • It is the provider’s responsibility to correct an outage as soon as possible 24x7x365 • It is user’s option to mitigate an outage (provide an alternative) • We do not allow bursting above reserved constraints (at least initially) • ABR policing requires special buffer management and datagram marking to guaranteethe performance

  8. Eerror Threshold • Connections are imperfect… • Frame loss rate not to exceed 1*10^-8 • If these are jumbo frames, then this is ~ 1*10^-12 BER • If FLR is less than this, the circuit is considered to be operating within acceptable limits • If FLR exceeds this rate, then the connection is considered to be failing • A “critical outage”

  9. Process • Outage procedures • Change Mangement • User support • Accounting • Policy coherency across domains

  10. Global Architecture Other collaborating inter-operable R&E GOLEs Other inter-operable R&E Networks and their available inter-domain connectivity LHCONE specific GOLEs LHCONE Networks (end sites – labs, campuses,…) And their associated LHCONE interconnectivty Result: A high capacity, highly interconnected, dynamically provisioned, multi-domain “express” core GOLE network with minimal transit policy constraints

  11. Global Architecture A second connection is provisioned across the interoperable R&E GOLE core A P2PCS connection instance is provisioned across the LHCONE core A subsequent connection utilizes a path across the core and a collaborating R&E network

More Related