1 / 11

Paris, 27 September 2005

Paris, 27 September 2005. D25 contribution on integration of NG-SDH into the control plane. Reference scenario. Domain 2 SDH network. UNI. UNI. Domain 1 SDH network. Domain 3 SDH network. Ethernet client. Ethernet client. Ethernet over SDH. A classical multi-layer issue

cicily
Download Presentation

Paris, 27 September 2005

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. Paris, 27 September 2005 D25 contribution on integration of NG-SDH into the control plane

  2. Reference scenario Domain 2 SDH network UNI UNI Domain 1 SDH network Domain 3 SDH network Ethernetclient Ethernetclient

  3. Ethernet over SDH • A classical multi-layer issue • The capabilities introduced by VCAT and LCAS: • Enable non-disruptive bandwidth modification • Allow scenarios increasing the resilience of the network • In order to take advantage of these options, control plane should be enhanced • Support of multi-layer calls. • Call and connection separation and support of calls composed of multiple connections. • Bandwidth modifications • Assuring end-to-end path diversity

  4. SNC SNC SNC SNC SNC SNC Reference Connection Points CP1 CP5 Client Layer (e.g. Ethernet) Layer Network Boundary Server Layer (e.g. SDH) Client to Server adaptation Client to Server adaptation VC-n-X Trail CP2 CP6 VC-n-Xv VC-n-Xv VC-n Trail VC-n Trail CP7 LC LC CP3 LC LC CP4 CP8 Domain 2 Domain 1

  5. Multi-layer calls • Two possible solutions: • Using a combined signaling sequence for the simultaneous establishment of both Ethernet and SDH connections. • Using separate signaling sequences for the establishment of the Ethernet connection and for the establishment of the supporting SDH connection(s). • Connection points must unambiguously be identified. • CP3, CP4, CP7, CP8 are identified by usual RSVP signaling (RSVP_HOP, LABEL objects) at SDH level • CP1 and CP5 are identified by usual RSVP signaling (RSVP_HOP, LABEL ?? objects) at Ethernet level • VCG connection points (CP2, CP6) could be referenced by the ASSOCIATION object (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt) or by the CALL_ID object (G.7713.2) • VCAT/LCAS indication support • By routing (maybe, not scalable) • During call setup, by the NOTIFY message and the LINK CAPABILTY object (draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt)

  6. Combined signaling sequence E-NNI UNI UNI Ethernet Ethernet SDH SDH Domain F D A SDH Domain E C B

  7. Separate signaling sequence E-NNI UNI UNI Ethernet Ethernet SDH SDH Domain F SDH Domain D A E C B

  8. Multi-layer calls • Combined signaling sequence: • requires the introduction of appropriate new objects necessary to carry client layer information within the server layer messages • is substantially inconsistent with the LSP hierarchy approach and it is difficult to use with multiple connections at the SDH level • Separate signaling sequences: • it allows coordination between the control plane and the SDH procedures related to VCAT and LCAS (important when LCAS is not employed and all the members must be set up before performing VCAT procedures).

  9. Call-Connection separation • ITU-T • CALL-ID object defined in G.7713.2. • May cause incompatibility problems even if for its class-num the default behavior is: “The node should ignore the object but forward it, unexamined and unmodified, in all messages resulting from this message” • IETF • Extension of the SESSION object (16 bits, short form) and SESSION_ATTRIBUTE object (long form) • May cause incompatibility problems due to the overloading of some fields.

  10. Bandwidth modifications • Adding/deleting a connection to (an) existing one(s). • Send a PATH message with same “Call identifier”, but different LSP_ID, TUNNEL_ID, MESSAGE_ID to create a new connection. • Modifying the bandwidth of an existing connection • Send a PATH message with same “Call identifier” and TUNNEL_ID, but different LSP_ID and MESSAGE_ID to modify the characteristics of the connection. The connection must have been set up using the SE style. • After the bandwidth is modified, the state for the old connection (the one with the original LSP_ID) can be deleted. • Both methods can be used with Ethernet and SDH calls. • The first method is more suited for SDH calls • The second one for Ethernet calls.

  11. Routing diversity • Domain diversity doesn’t assure path diversity. The paths can join somewhere in the destination domain. • If the path for the single connections is calculated by the source node, it could be impossible to assure diversity. This is true also if the path within a domain is calculated by the ingress node. • An external element must be adopted → PCE. • End-to-end path calculation can be achieved by coordinating PCEs from the different domains • Diversity within the domain can be achieved by providing the PCE of the domain with the “call identifier” of every connection.

More Related