用于MPLS流量工程的RSVP信令扩展.docx

上传人:b****6 文档编号:7700723 上传时间:2023-01-25 格式:DOCX 页数:26 大小:475.92KB
下载 相关 举报
用于MPLS流量工程的RSVP信令扩展.docx_第1页
第1页 / 共26页
用于MPLS流量工程的RSVP信令扩展.docx_第2页
第2页 / 共26页
用于MPLS流量工程的RSVP信令扩展.docx_第3页
第3页 / 共26页
用于MPLS流量工程的RSVP信令扩展.docx_第4页
第4页 / 共26页
用于MPLS流量工程的RSVP信令扩展.docx_第5页
第5页 / 共26页
点击查看更多>>
下载资源
资源描述

用于MPLS流量工程的RSVP信令扩展.docx

《用于MPLS流量工程的RSVP信令扩展.docx》由会员分享,可在线阅读,更多相关《用于MPLS流量工程的RSVP信令扩展.docx(26页珍藏版)》请在冰豆网上搜索。

用于MPLS流量工程的RSVP信令扩展.docx

用于MPLS流量工程的RSVP信令扩展

用于MPLS流量工程的RSVP信令扩展

Juniper网络公司,爱立信公司,1999年

 

大纲…………………………………………………………………………………………………………4

观点…………………………………………………………………………………………………………4

介绍…………………………………………………………………………………………………………4

RSVP的发展…………………………………………………………………………………………………7

运行总的看法:

RSVP扩展以支持LSP隧道……………………………………………………………8

LSP隧道……………………………………………………………………………………………9

建立一条LSP隧道………………………………………………………………………………10

RSVPPATH信息………………………………………………………………………10

RSVPRESV信息………………………………………………………………………11

预留类型…………………………………………………………………………………………11

RSVP隧道信息详细资料…………………………………………………………………………………11

PATH信息………………………………………………………………………………………12

LABEL_REQUEST对象………………………………………………………………………12

EXPLICIT_ROUTE对象(ERO)……………………………………………………………13

RECORD_ROUTE对象(RRO)……………………………………………………………14

SESSION,SENDER_TEMPLATE,FLOW_SPEC,及FILTER_SPEC对象C型扩展…15

SESSION_ATTRIBUTE对象…………………………………………………………………16

RSVP信息………………………………………………………………………………………17

LABEL对象……………………………………………………………………………17

扩展的RSVP是如何建立一条LSP隧道………………………………………………………………18

PATH信息………………………………………………………………………………………19

LSR1(输入LSR)处的处理………………………………………………………20

LSR2处的处理…………………………………………………………………………20

LSR3处的处理…………………………………………………………………………21

LSR4(输出LSR)处的处理………………………………………………………21

RSVP信息………………………………………………………………………………………21

LSR4(输出LSR)出的处理…………………………………………………………21

LSR3处的处理…………………………………………………………………………22

LSR2处的处理…………………………………………………………………………22

LSR1(输入LSR)处的处理………………………………………………………22

业务如何通过LSP进行传输………………………………………………………………………………23

现有的LSP隧道如何进行重路由………………………………………………………………………23

预留类型………………………………………………………………………………………24

固定滤波器(FF)类型………………………………………………………………24

共享明确(SE)类型…………………………………………………………………25

LSP隧道重路由处理……………………………………………………………………………25

建立初始LSP隧道……………………………………………………………………26

将来重路由LSP隧道…………………………………………………………………26

为Internet核心而增强的RSVP可扩展性………………………………………………………………27

捆绑信息扩展……………………………………………………………………………………28

MESSAGE_ID扩展……………………………………………………………………………29

MESSAGE_ID对象……………………………………………………………………29

MESSAGE_ID_ACK对象……………………………………………………………30

更新扩展的摘要………………………………………………………………………………30

Hello协议扩展……………………………………………………………………………………30

结论…………………………………………………………………………………………………………31

参考…………………………………………………………………………………………………………31

Internet草案………………………………………………………………………………………31

RFC………………………………………………………………………………………………32

参考书籍…………………………………………………………………………………………32

其它参考…………………………………………………………………………………………32

 

大纲

Internet服务提供商(ISP)们不断面临来自于在管理他们的网络高速增长的同时,维持一个用于重要任务应用的可靠基础结构方面的挑战。

多协议标记交换(MPLS),由于其支持流量工程,而在新型公共网络中被作为一项重要的技术。

流量工程是通过将大量的用户业务转移到经过服务提供商网络中特定节点的预先设定的路径来实现的。

这些预先设定的路径被称作标记交换路径(LSP)。

这篇白皮书将阐述IETF的资源预留协议(RSVP)是如何被扩展而能够自动建立穿过服务提供商网络的LSP。

白皮书的第一部分将讨论流量工程的方法,然后讨论传统的RSVP是如何被扩展一支持MPLS的LSP信令。

白皮书的核心部分提供的详细的例子来说明如何使用RSVP建立LSP,用户业务如何通过LSP,及LSP在网络故障时如何进行重路由。

白皮书总结了最新的RSVP扩展如何解决传统RSVP“软状态”模式所面临的扩展性和稳定性问题。

同时,这篇白皮书还提供了一些RSVP的背景信息,它假设您对在RFC2205机RFC2209中定义的传统RSVP有一个基本的了解。

观点

由于手动配置一条LSP的开销非常大,许多服务提供商希望通过使用信令协议自动完成这一处理。

LSP的明确路由可以通过定制的管理工具离线计算,或使用基于约束的路由在线计算。

信令协议在由明确路由计算处理选定的网络节点分配标记及建立LSP转发状态。

本白皮书中所描述的RSVP扩展允许服务提供商动态的建立通过其网络的LSP,使网络对不断变化的条件作出更为有效的反映,同时节约了时间并减少了运行费用。

介绍

流量工程参与将业务流映射到网络物理拓扑上的任务,它提供了将业务流重通过内部网关协议(IGP)计算出的最短路径转移到一条具有更少阻塞的路径上去的能力(图1)。

流量工程的目的

图1:

流量工程

在于在网络中的不同链路,路由器及交换机之间均衡业务流,使这些网络组成部分不会被过分使用或未被充分使用。

流量工程使Internet服务提供商能够充分使用他们的网络基础结构。

关于Juniper网络公司流量工程结构的详细描述,请参考白皮书“新型公共网络中的流量工程”。

因为流量工程是一个极为有力的工具,通过将处理自动化及使服务提供商可以简单地在其骨干网中实施流量工程,可以获得许多好处:

Ø减少了管理机运行的费用

Ø网络运行最为有效

Ø在网络压力及不稳定期间进行动态的流量工程

Ø为增值业务及附加业务提供可靠的基础结构

Juniper网络公司的MPLS流量工程结构包括4个基本组成部分:

Ø信息发布机制提供可用网络资源信息--这一部分通过定义相关的IGP简单扩展来实现,使链路属性作为每个路由器链接状态广播的一部分。

包括最大链接带宽,最大可预留带宽,当前预留带宽,当前带宽使用及链接着色等流量工程扩展被加到IGP链接状态广播中去。

Ø路径选择处理部分使用IGP链接状态广播所发布的信息选择一条满足业务流特定需求的路径--这一处理既可以通过离线计算来实现,也可以通过使用基于约束的路由在线完成。

Ø信令部分用来预留资源及由LSP路由计算处理选择的网络节点上建立路径状态。

在Juniper网络公司结构中,这一任务通过配置一些IETF认可的RSVP扩展来实现,这些扩展使RSVP能够在MPLS网络中作为信令协议工作。

这篇白皮书将主要讨论这些扩展。

Ø分组转发部分(MPLS)将业务沿由基于约束路由计算所得到的明确路径进行转发--有关MPLS的详细讨论及其在服务提供商网络中的应用,请参考Juniper网络公司的白皮书“多协议标记交换:

新型公共网络中的增强路由”。

很明显,负责建立穿过网络的LSP状态的信令协议在自动流量工程处理中扮演着重要的角色。

一个成功的信令解决方案需要提供于LSP隧道运行有关的许多重要任务:

Ø提供建立一条区别于“普通”IGP计算路径的明确路由LSP的机制。

一条明确路由是一系列预先配置的作为LSP物理路径一部分的LSR。

Ø提供下行标记分配,发布及按路径中的LSR需求进行捆绑,进而在网络节点中建立路径状态。

Ø沿路径随机地提供资源预留或服务等级以满足业务流的需求。

Ø为网络管理员提供LSP使用的实际路由信息。

Ø支持全局及局部修复以动态重路由一条LSP,使其避开网络阻塞及故障。

Ø重新分配以前分配的网络资源,通过管理策略控制抢占现存LSP,以建立新的、承载更为重要业务的LSP。

Ø在LSP建立初始及重路由现有LSP时阻止循环形成。

Ø监测及管理明确路由LSP的状态。

Juniper网络公司流量工程结构的信令部分基于一组IETF认可的RSVP扩展,以支持所有这些功能要求。

RSVP的发展

90年代中期,RSVP被开发以防止网络阻塞,它通过允许路由器事先决定它们是否能够满足应用流的需求,然后在可能的情况下预留所需资源来完成。

最初,RSVP被设计成为主机间的特定业务流安装与资源预留有关的转发状态。

穿过服务提供商网络业务流的物理路径通过传统的基于目的的路由(即,IGP)来确定。

到1997,RSVP成为被建议的标准,现在被广泛配置在IP网络设备中。

但是,RSVP并未在服务提供商网络中广泛应用,因为运行人员关心其需要潜在地支持数百万条主机-主机业务流的扩展性及开销。

图2:

传统RSVP与扩展的RSVP的比较

最初的MPLS设备选择扩展RSVP成为信令系统以支持LSP的建立,使其能够自动地绕开网络故障及阻塞。

RSVP通过自动进行流量工程处理提供了简化网络运行所需的重要部分。

作为流量工程信令协议应用RSVP与其原本在90年代中期开发者的预想大不相同(见图2):

Ø在基本的RSVP规范(RFC2205和FRC2209)上增加了许多扩展以支持明确路由LSP的建立及管理。

ØRSVP信令发生在一对作为业务中继输入及输出点的路由器(而不是主机对)之间。

扩展的RSVP安装状态并应用于一组共享一条公用路径和共享网络资源的业务流的集合,而不是应用于单条的主机到主机的业务流。

通过汇集许多主机到主机业务流至一条LSP隧道,扩展的RSVP明显地减少了服务提供商网络核心部分管理所需的RSVP状态数量。

ØRSVP信令安装与分组转发有关的分布的状态,包括MPLS标记分配。

ØRSVP的软状态模型的扩展性,迟延,及业务开销通过一系列扩展减少了刷新信息数量及相关的信息处理需求。

Ø通过RSVP信令建立的路径并不被传统的基于目的的路由所限制,因此,它是建立流量工程中继的优秀工具。

在1997年初,最初的MPLS设备有许多原因选择扩展RSVP而不是设计一个全新的信令工具以支持流量工程需求。

ØRSVP原来被设计成为Internet资源预留协议,为在一系列多点传送或单点传送传输路径中建立及管理分布的预留状态提供了一个通用的工具。

资源预留是流量工程的一个重要的部分,因此,为这一目的继续使用RSVP而不是从头开始设计是有意义的。

ØRSVP通过允许承载不透明对象的设计以支持扩展机制--RSVP在其消息部分将对象作为一块不透明的信息承载而在路由器中提供适当的控制模块。

这种基本的设计鼓励了对用于建立和维护信息分布状态的新RSVP对象的开发,而不是纯粹的资源预留。

流量工程的设计者相信可以快速、简单地开发出一系列扩展以增强RSVP支持重要的流量工程需求--明确路由及标记发布。

Ø被推荐的扩展并未使扩展的RSVP实施与传统的RSVP实施不兼容--RSVP的实施可以通过对消息部分所包含的对象进行简单地检验容易地区别LSP信令和标准的RSVP预留。

Ø通过实施建议的扩展,RSVP提供了一个无与伦比的信令系统,它提供了网络管理人员动态建立LSP所需的所有需求:

Ø扩展的RSVP沿一条明确路由建立LSP以支持大型服务提供商对流量工程的需求。

Ø扩展的RSVP通过为在LSP中的LSR分配标记捆绑信息来建立LSP状态。

Ø扩展的RSVP能够对在LSP中的LSR预留网络资源(传统RSVP的角色)。

扩展的RSVP同时也允许LSP不做特殊的资源预留而承载最努力的业务。

运行上总的看法:

RSVP扩展以支持LSP隧道

这一部分将提供一个概要的观点来阐述基本的RSVP规范是如何被扩展以支持LSP隧道的建立。

它着重在以下要点:

ØLSP隧道

ØRSVP消息类型

Ø预留类型

LSP隧道

在Juniper网络公司的流量工程体系结构中,输入LSR基于IBGP下一跳决定哪些分组被分配到特定的LSP。

输入LSR通过输出LSR学习到远端的报头,在同一自治域(AS)内的路由器使用IBGP,而不是EBGP来交换路由信息。

输出LSR使用EBGP与不同AS内的输入LSR进行通信。

图3:

输入LSR基于IBGP下一跳选择输出LSR

服务提供商通常希望能够设计一条在输入和输出LSR之间的传输路径。

依靠IBGP下一跳是实现这一任务的方便的方法,同时也提供了将潜在的数千条IP报头汇集到一个MPLS标记中的好处。

这种实现方法可以明显地减少建立穿过服务提供商网络所需LSP隧道的数量。

同时,这种实现方法提供了一个强有力的工具,减少了在大型服务提供商网络互联交换节点间通信的信息量。

在图3中,到ISP的输入LSR通过使用单一的LSP将位于或可通过ISP1或ISP2到达的报头的所有业务转发至到输出LSR。

一旦输入LSR分配给分组一个标记,此标记将有效地定义业务流至穿过服务提供商骨干网的LSP。

LSP通常是指一条LSP隧道,因为业务流通过它时对于LSP所包括的每个中间LSR是不透明的。

为支持LSP隧道特性,扩展的RSVP定义了一个新的RSVP会话期对象,称作LSP_TUNNEL_Ipv4。

这类对象通知每个LSR,属于特定LSP隧道的业务必须基于由此会话期中到上行发送者的本地LSR分配的带有特定标记的前一跳进行识别。

这里,我们知道,基本的RSVP规范只定义了两个会话期C-类型,IPv4/UDP会话期对象和IPv4/UDP会话期对象。

建立一条LSP隧道

为建立一条LSP隧道,输入LSR发送一个RSVPPATH消息下行至输出LSR。

输出LSR通过向输入LSR发送一个上行RSVPRESV信息对接收到RSVPPATH消息作出反应。

当输入LSR接收到RSVPRESV消息时,LSP被建立,输入LSR可以使用LSP隧道将业务转发至输出LSR(图4)。

图4:

建立一条LSP隧道

RSVPPATH消息

输入LSR产生一个带有LSP_TUNNEL_IPv4类型的会话期的RSVPPATH消息。

PATH消息包含一个LABEL_REQUEST对象以请求中间LSR和输出LSR为此路径提供一个标记捆绑。

如果路径中并不是每个LSR都支持LABEL_REQUEST对象,则此不支持LABEL_REQUEST对象路径中的第一个LSR会通知输入LSR。

除LABEL_REQUEST对象外,RSVPPATH消息中还包括其它一些可选对象:

ØEXPLICIT_ROUTE对象(ERO)--可被增加以为穿过服务提供商网络LSP指定一条的预先定义路径。

当ERO出现时,RSVPPATH信息沿由ERO指定的路径向输出LSR方向被转发,不受IGP最短路径的约束。

ØRECORD_ROUTE对象(RRO)--允许输入LSR接收LSP隧道穿过服务提供商网络所经过的LSR列表。

ØSESSION_ATTRIBUTE对象--可被包含在RSVPPATH消息内以保证会话期鉴定及诊断。

SESSION_ATTRIBUTE对象同时业控制路径建立优先级,支持优先级,和本地重路由特性。

这些特性将在下面进行讨论。

RSVPRESV消息

当输出LSR接收到包含LABEL_REQUEST对象的PATH消息时,它通过传输一个包含LABEL对象的RESV消息作出反应。

LABEL对象包含下行LSR与其上行邻居通信所用的标记捆绑。

RESV消息向输入LSR的上行方向发送,其方向与PATH消息发送方向相反。

每个处理带有LABEL对象的RESV消息的LSR对与特定LSP相关联的输出业务使用接收标记。

当RESV消息到达输入LSR时,LSP被建立。

预留类型

每个LSP必须采用一个明确的预留类型被建立。

预留类型通过输出LSR单独地被确定。

但是,Juniper网络公司的实施方案可以通过设置或清除PATH消息内的SESSION_ATTRIBUTE对象所包含的“输入节点可以重路由位”来允许输入LSR向输出LSR表达其希望的预留类型(如下所述)。

输出LSR可以从RSVP固定滤波器(FF)或RSVP共享明确(SE)预留类型中选择。

传统的RSVP通配符滤波器(WF)预留类型因为其合并规则及流量工程目的应用的缺陷而未被使用。

正象我们将要在这篇白皮书后面看到的,预留类型是一个非常重要的角色,因为它决定了RSVP信令如何支持LSP的基本功能--对一条已有的LSP隧道进行重路由。

RSVP隧道消息细节

这一部分将详细讨论为标准RSVPPATH及RESV消息支持流量工程所作的IETF认可的行令扩展。

PATH消息

当希望建立一条LSP隧道时,PATH消息将由输入LSR向输出LSR方向传送。

PATH消息的地址被定义为指向输出LSR,但是其在IP报头中包含了路由器告警IP选项(RFC2113)以表示报文需要中间路由器对其进行特殊处理。

PATH消息可以包括多种不同的RSVP对象:

ØLABEL_REQUEST对象

ØEXPLICIT_ROUTE对象

ØRECORD_ROUTE对象

ØSESSION_ATTRIBUTE对象

ØCoSFLOWSPEC对象

LABEL_REQUEST对象

为建立一条LSP隧道,输入LSR将产生一条包含LABEL_REQUEST对象的PATH消息。

LABEL_REQUEST对象的存在表示这条LSP需要标记捆绑。

LABEL_REQUEST对象同时也包含第三层协议ID(L3PID)用于识别将在LSP隧道中传输的第三层协议。

需要L3PID是因为假设LSP隧道传输IPv4业务是不可能的--L3协议不能够从L2报头获得,只能简单的识别MPLS为更高一层的协议。

共有3种可能的LABEL_REQUEST对象类型:

Ø请求不定义特定标记范围的标记--这是一种普通的情况,MPLS标记在位于数据链路层和网络层报头之间的标准MPLS添加报头中承载。

Ø请求定义了带有最小和最大VPI及VCI值的ATM标记范围的标记--这种类型的请求在MPLS标记由第二层ATM报头承载时十分有用。

Ø请求定义了带有最小和最大DLCI值的帧中继标记范围的标记--这种类型的请求在MPLS由第二层帧中继报头承载时十分有用。

当一条PATH消息到达一个LSR时,该LSR将LABEL_REQUEST对象存储在此LSP的本地路径状态模块中。

如果定义了标记范围,则标记分配处理必须在这一范围内分配标记。

可能的错误条件包括:

Ø如果接收到PATH消息的LSR识别出LABEL_REQUEST对象,但并不能分配标记,其将向输入LSR发送一条PathErr消息(表示一个路由问题或MPLS标记分配故障)。

Ø如果接收方不支持L3PID,其将向输入LSR发送PathErr(路由问题/不支持L3PID)--这个错误将导致LSP建立会话期失败。

Ø如果收到信息的LSR未能识别出LABEL_REQUEST对象,其将向输入LSR发送PathErr(未知的对象类别)--这个错误将导致LSP建立失败。

EXPLICIT_ROUTE对象(ERO)

通过对PATH消息增加EXPLICIT_ROUTE对象(ERO),输入LSR可以为LSP定义一条预先确定的明确路由,而与传统的IP路由独立。

ERO只能用于单点传送应用及必须所有明确路由上的路由器都支持RSVP和ERO的情况。

一条明确路由通过一系列包含在ERO内的子对象进行编码。

每个子对象能够识别明确路由中的一组节点或定义沿路径执行的一个操作。

因此,一条明确路由是路径中一组规定的需要通过的节点和一组需要执行的操作。

每组节点被称作一个抽象节点。

如果一个抽象节点只包括一个节点,它被称作简单抽象节点。

例如,一条明确路由可只由AS号子对象组成。

同时每个AS可能包含多个跳转点,对于明确路由,它们对源节点是不透明的。

图5说明了每个子对象是如何在ERO中进行编码的。

图5:

ERO子对象编码

L

类型

长度

子对象内容

如果设置了L位,子对象在明确路由中将描述成疏松跳转。

如果L位被清除,则其在明确路由中为精确跳转。

目前共定义了4种类型的EXPLICIT_ROUTE子对象:

ØIPv4报头--识别一个抽象节点包含具有IP报头为IPV4的一系列节点。

具有32位长度的报头表示一个IPV4节点。

ØIPV6报头--识别一个抽象节点包含具有IP报头为IPV6的一系列节点。

具有128位长度的报头表示一个IPV6节点。

Ø自治域号码--识别一个节点包含一系列属于同一自治域的节点。

ØMPLSLSP终止--表明优先抽象节点应当从所有使用这一LSP隧道的分组中移去一级标记堆栈。

图6描述了使用32位IPV4报头定义的精确明确路由。

图6:

明确路由例子

明确路由中疏松节点的存在意味着短时间内在覆盖型路由协议中可能会产生转发循环,LSP隧道中的循环可以通过RECORS_ROUTE对象检测到,如下面所讨论的。

RECORD_ROUTE对象(RRO)

通过对PATH消息增加RECORD_ROUTE对象(RRO),输入LSR可以接收到LSP隧道穿过的实际路由的信息。

RRO的内容是一组被称作子对象的数据项。

目前定义了两种类型的子对象,IPV4地址和IPV6地址。

在RSVP信令中,RRO共有3种可能的应用:

Ø发现层3路由循环或明确路由的固有循环,这是因为RRO与路径向量类似。

Ø一跳接一跳的收集LSP建立会话期的最新详细路径信息。

Ø通过较小的改变,它可以输入到EXPLICIT_ROUTE对象中。

其将被用于下一条PATH消息中的EXPLICIT_ROUTE对象以“锁定会话期路径”。

如果LSP被锁定,其将不允许改变,即便有更好的路径出现。

当输入LSR试图建立一条LSP隧道时,它将产生一条包含LABEL_REQUEST对象的PATH消息。

PATH消息也可以同时包含一个RRO对象。

最初的RRO包含输

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 表格模板 > 合同协议

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1