RFC 10066 přidává do PCEP váhy, podle kterých se provoz rozdělí mezi víc tras
IETF vydalo 26. října RFC 10066. Rozšiřuje protokol PCEP tak, aby řídicí prvek poslal hlavovému směrovači k jedné cestě několik tras a u každé váhu, v jakém poměru po ní má téct provoz. Dosud šel na jednu kandidátní cestu segmentového směrování poslat jen jeden seznam segmentů.

Velké páteřní sítě už dávno neposílají provoz jen tam, kam ukazuje nejkratší cesta. Trasu spočítá vyčleněný prvek, kterému se říká PCE, a hlavovému směrovači ji pošle protokolem PCEP ze RFC 5440. U segmentového směrování se takové zadání jmenuje SR Policy a popisuje ho RFC 9256: jedna politika má jednu nebo víc kandidátních cest a každá kandidátní cesta může být složená z několika seznamů segmentů, mezi které se provoz rozdělí.
Protokol to ale neuměl popsat. PCEP váže na jednu LSP právě jeden objekt ERO, tedy jednu trasu, a rozšíření pro SR Policy (RFC 9862) nechalo víc seznamů segmentů schválně mimo svůj rozsah. Směrovač tak od PCE dostal jednu trasu, i když jich politika unese několik. To mění RFC 10066, které IETF vydalo 26. října 2026 jako dokument standardizační řady.
Oddělovač mezi trasami a váha u každé z nich
Nový objekt PATH-ATTRIB stojí vždy před objektem ERO nebo RRO a popisuje právě tu trasu, která za ním následuje. Když jich je víc, musí PATH-ATTRIB předcházet každé z nich, takže zároveň slouží jako oddělovač. Nese 32bitový identifikátor trasy, tříbitový provozní stav a příznak R, kterým se označí trasa vedoucí opačným směrem.
Poměr provozu nastavuje TLV MULTIPATH-WEIGHT uvnitř PATH-ATTRIB. Je v něm jediné 32bitové číslo bez znaménka a podíl toků se počítá jako poměr té váhy k součtu vah všech tras. Když TLV chybí, platí váha 1. Nula u SR Policy znamená, že je seznam segmentů podle oddílu 5.1 RFC 9256 neplatný a nenese žádný provoz – dá se tím trasa odstavit, aniž směrovač zapomene, kudy vedla. Nula u všech tras naráz shodí celou kandidátní cestu.
| Název | Číslo | K čemu je |
|---|---|---|
| PATH-ATTRIB (objekt) | třída 45, typ 1 | hlavička jedné trasy a oddělovač mezi nimi |
| MULTIPATH-CAP (TLV) | 60 | dohoda o podpoře a o počtu tras |
| MULTIPATH-WEIGHT (TLV) | 61 | váha jedné trasy |
| MULTIPATH-OPPDIR-PATH (TLV) | 63 | odkaz na trasu v opačném směru |
| MULTIPATH-FORWARD-CLASS (TLV) | 76 | třída provozu pro cestu podle toků |
Čísla jsou v rejstřících PCEP u organizace IANA, kde si je dokument držel jako dočasné přidělení už od roku 2022.
Zpětná trasa ke každé dopředné
Druhá polovina rozšíření míří na obousměrné cesty. PCEP uměl spárovat dvě kandidátní cesty opačných směrů, ale ne jednotlivé seznamy segmentů uvnitř nich. TLV MULTIPATH-OPPDIR-PATH to doplňuje: v hlavičce jedné trasy odkáže na identifikátor trasy, která vede zpátky. Takových odkazů smí být v jedné hlavičce několik, protože dopředná trasa přes uzel s rovnoběžnými linkami potřebuje na zpáteční cestě pokrýt všechny.
Dva příznaky říkají, jak těsně k sobě ten pár patří. N znamená, že obě trasy vedou přes tytéž uzly, L že i přes tytéž linky. Má to praktický důvod: když směrovač zná zpáteční seznam ke každému dopřednému, může nad každou trasou zvlášť pustit měření výkonu nebo detekci výpadku BFD a poznat poruchu v obou směrech. Dokument u toho výslovně upozorňuje, že příznaky popisují stav v okamžiku odeslání zprávy a nezaručují, že souběh vydrží i při místní opravě trasy.
Tentýž den vydalo IETF RFC 10067, které spáruje dvě jednosměrné SR cesty na úrovni celé kandidátní cesty. Obě specifikace na sebe odkazují a vyšly s odstupem čtvrt hodiny.
Dohoda hned na začátku relace
Aby si strany nerozuměly špatně, zavádí dokument TLV MULTIPATH-CAP. Posílá se v objektu OPEN při navazování relace a volitelně i u jednotlivých LSP, kde přebije nastavení relace. Vedle čtyř příznaků pro jednotlivé funkce nese šestnáctibitový počet tras: od směrovače říká, kolik jich umí nainstalovat, od PCE kolik jich umí spočítat. Nula znamená bez omezení a PCE nesmí vrátit víc, než je nižší z obou čísel. Když TLV chybí v OPEN i v objektu LSP, chová se relace postaru.
Právě to číslo řeší i oddíl o bezpečnosti. Víc tras na jednu LSP znamená víc stavu na směrovači, takže pokažený nebo ovládnutý PCE by mu ho mohl nafouknout rozvětvením na maximum. Dokument proto operátorům doporučuje nastavit nenulovou mez a pouštět rozšíření jen na relacích chráněných TLS.
Pět let a třicet revizí
Práce na dokumentu začala v pracovní skupině PCE 3. května 2021 první verzí konceptu draft-ietf-pce-multipath. Poslední, třicátá verze je z 23. června 2026 a vydání přišlo o čtyři měsíce později. Editory jsou Mike Koldychev z Cieny a Samuel Sidor z Cisca; mezi spoluautory, které pokyny IETF o počtu jmen na titulní straně odsunuly do oddílu přispěvatelů, jsou lidé z Cieny, Cisca, Juniperu, Nokie, Huawei a Verizonu.
Nástroje zatím ukazují koncept
Analyzátor Wireshark rozšíření zná, jenže podle starších verzí konceptu. V jeho dekodéru PCEP stojí u objektu PATH-ATTRIB odkaz na pátou verzi a u dvojice TLV 60 a 61 na dvanáctou. Tabulka jmen TLV proto končí u čísla 61 a přeskakuje rovnou na 64, takže MULTIPATH-OPPDIR-PATH ani MULTIPATH-FORWARD-CLASS v ní nejsou a vypíšou se jako neznámé. Příznaky v MULTIPATH-CAP naopak rozebírá všechny včetně jednoho navíc: bit, na kterém čte podporu TLV MULTIPATH-BACKUP, nechává hotové RFC nepřidělený. Poslední změna toho souboru je z 18. ledna 2026 a týkala se úklidu kódu, ne rozšíření.
Podobně pozadu je i rejstřík IANA. Den po vydání u všech pěti přidělených čísel pořád stojí odkaz na devětadvacátou verzi konceptu místo na číslo RFC – redakční zápis tenhle krok dělá se zpožděním a samotné přidělení platí dál.
Zdroje
- RFC 10066: Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information, IETF
- Záznam dokumentu rfc10066, IETF Datatracker
- Path Computation Element Protocol (PCEP) Numbers, IANA
- RFC 10067: PCEP Extensions for Associated Bidirectional Segment Routing (SR) LSPs, IETF
- packet-pcep.c, repozitář Wiresharku