RFC 4379 - 1. Introduction
1. Introduzione (Introduction)
Questo documento descrive un meccanismo semplice ed efficiente che può essere utilizzato per rilevare guasti del piano dati nei percorsi a commutazione di etichetta (Label Switched Path, LSP) di reti Multi-Protocol Label Switching (Multi-Protocol Label Switching, MPLS). Il documento si compone di due parti: le informazioni trasportate in un "echo request" e in un "echo reply" MPLS, e i meccanismi per trasportare l'echo reply. La prima parte mira a fornire informazioni sufficienti per verificare il corretto funzionamento del piano dati, nonché un meccanismo per convalidare il piano dati rispetto al piano di controllo e localizzare così i guasti. La seconda parte suggerisce due metodi di canale di risposta affidabile per il messaggio echo request, per un isolamento dei guasti più robusto.
Una considerazione importante in questa progettazione è che gli MPLS echo request seguono lo stesso percorso dati che seguirebbero i normali pacchetti MPLS. Gli MPLS echo request servono in primo luogo a convalidare il piano dati e in secondo luogo a verificare il piano dati rispetto al piano di controllo. I meccanismi per verificare il piano di controllo sono preziosi, ma non sono trattati in questo documento.
Questo documento fa un uso speciale dell'intervallo di indirizzi 127/8. Si tratta di un'eccezione al comportamento definito nella RFC 1122 [RFC1122] e aggiorna tale RFC. La motivazione di questa modifica e i dettagli di questo uso eccezionale sono discussi nella sezione 2.1 seguente.
1.1. Convenzioni (Conventions)
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nella RFC 2119 [KEYWORDS].
Il termine "Must Be Zero" (MBZ) è usato nelle descrizioni degli oggetti per i campi riservati. Tali campi MUST essere posti a zero in trasmissione e ignorati in ricezione.
La terminologia relativa alle reti private virtuali (Virtual Private Network, VPN) di livello L2 e L3 è definita in [RFC4026].
Poiché questo documento fa riferimento al Time to Live (TTL) MPLS molto più spesso che al TTL IP, gli autori hanno scelto la convenzione di usare "TTL" senza qualificazione per indicare il "TTL MPLS" e "IP TTL" per il valore TTL nell'intestazione IP.
1.2. Struttura di questo documento (Structure of This Document)
Il corpo di questo memo contiene quattro parti principali: la motivazione, il formato dei pacchetti MPLS echo request/reply, il funzionamento dell'LSP ping e un percorso di ritorno affidabile. Si suggerisce ai lettori che affrontano l'argomento per la prima volta di saltare i formati dei pacchetti veri e propri e di leggere prima la teoria del funzionamento (Theory of Operation); il documento è strutturato in questo modo per evitare riferimenti in avanti.
1.3. Contributori (Contributors)
Le seguenti persone hanno dato contributi essenziali a tutti gli aspetti di questo documento, e gran parte del materiale è nato dal dibattito e dalle discussioni all'interno di questo gruppo.
- Ronald P. Bonica, Juniper Networks, Inc.
- Dave Cooper, Global Crossing
- Ping Pan, Hammerhead Systems
- Nischal Sheth, Juniper Networks, Inc.
- Sanjay Wadhwa, Juniper Networks, Inc.