In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs). This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]
IETF · RFCОфициальная английская аннотация
In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs). This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]
{
"id": "RFC5150",
"number": 5150,
"title_en": "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)",
"title_ru": "",
"summary_ru": "",
"purpose_ru": "",
"use_ru": "",
"full_translation_path": "",
"full_translation_checked_at": "",
"full_translation_source_sha256": "",
"architect_note_ru": "",
"topics_ru": [],
"translation_state": "not_prepared",
"verification_level": "not_prepared",
"verification_level_ru": "Русская выжимка не подготовлена",
"verification_note_ru": "",
"abstract_en": "In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as \"LSP stitching\", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as \"LSP segments\" (S-LSPs). This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]",
"authors": [
"A. Ayyangar",
"K. Kompella",
"JP. Vasseur",
"A. Farrel"
],
"organizations": [],
"publication_date": "2008-02-01",
"current_status": "PROPOSED STANDARD",
"current_status_ru": "Предлагаемый стандарт",
"publication_status": "PROPOSED STANDARD",
"publication_status_ru": "Предлагаемый стандарт",
"lifecycle": "active",
"lifecycle_ru": "Действующий",
"stream": "IETF",
"stream_ru": "IETF",
"area": "rtg",
"area_ru": "Маршрутизация",
"working_group": "ccamp",
"source_draft": "draft-ietf-ccamp-lsp-stitching-06",
"page_count": 19,
"doi": "10.17487/RFC5150",
"keywords": [
"lsp",
"label switched paths",
"e2e lsp",
"lsp stitching",
"lsp segments",
"s-lsp"
],
"formats": [
"TXT",
"HTML"
],
"relations": {
"obsoletes": [],
"obsoleted_by": [],
"updates": [],
"updated_by": [],
"is_also": [],
"see_also": []
},
"links": {
"info": "https://www.rfc-editor.org/info/rfc5150/",
"html": "https://www.rfc-editor.org/rfc/rfc5150.html",
"txt": "https://www.rfc-editor.org/rfc/rfc5150.txt",
"datatracker": "https://datatracker.ietf.org/doc/rfc5150/"
}
}