所选语种没有对应资源,请选择:

本站点使用Cookies,继续浏览表示您同意我们使用Cookies。Cookies和隐私政策>

提示

尊敬的用户,您的IE浏览器版本过低,为获取更好的浏览体验,请升级您的IE浏览器。

升级

S9300, S9300E, S9300X V200R010C00 配置指南-MPLS

本文档介绍了设备支持的MPLS相关配置。主要内容包括静态LSP的基本原理和配置过程、MPLS LDP的基本原理和配置过程、MPLS QoS的基本原理和配置过程、MPLS TE的基本原理和配置过程、MPLS OAM的基本原理和配置过程、Seamless MPLS的基本原理和配置过程,并提供相关的配置案例。
评分并提供意见反馈 :
华为采用机器翻译与人工审校相结合的方式将此文档翻译成不同语言,希望能帮助您更容易理解此文档的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 华为对于翻译的准确性不承担任何责任,并建议您参考英文文档(已提供链接)。
路径建立

路径建立

路径建立方式简介

CR-LSP建立方式

CR-LSP的建立方式可以分为静态建立和动态建立。

静态CR-LSP的建立完全依靠企业网络管理员的手工配置,这里只介绍使用RSVP-TE信令建立动态CR-LSP的原理。

RSVP-TE简介

资源预留协议RSVP是为Integrated Service模型而设计的,用于在一条传输路径的各节点上进行带宽资源预留。这种带宽预留能力使得其非常适合作为MPLS TE路径建立的信令协议。

RSVP-TE在原始RSVP协议进行了一定程度的扩展以满足MPLS TE的要求。RSVP-TE对RSVP扩展的内容主要有:
  • Path消息中引入Label Request对象,支持发起标签请求;在Resv消息中引入Label对象,支持标签分配。

  • 扩展的消息除了可以携带标签绑定信息外,还可以携带路径约束条件信息。

  • 通过扩展对象支持MPLS-TE带宽约束条件,使其具有资源预留功能。

RSVP消息类型

RSVP消息分为如下几类:

  • Path消息:由发送者向下游转发,保存所经过的节点的路径信息。

  • Resv消息:由接收者向上游逐跳转发,用于响应Path消息,提出资源预留请求。

  • PathErr消息:RSVP节点在处理Path消息时,如果发生错误,就向上游发送PathErr消息。

  • ResvErr消息:RSVP节点在处理Resv消息时,如果发生错误,就向下游发送ResvErr消息。

  • PathTear消息:用来删除节点路径信息,其作用与Path消息相反。

  • ResvTear消息:用来删除节点预留状态,其作用与Resv消息相反。

  • ResvConf消息:由发送者向下游逐跳转发,用于确认资源预留请求。在Resv消息中包含RESV_CONFIRM对象时才会发送ResvConf消息。

  • Srefresh消息:用来刷新RSVP状态。

RSVP-TE工作原理
RSVP-TE在MPLS TE中的工作原理如表5-4所示。
表5-4  RSVP-TE工作原理

功能

描述

动态CR-LSP的建立

根据CSPF的路径计算结果或者严格显式路径建立CR-LSP。路径建立由隧道入节点发起。

动态CR-LSP的维护

  • 路径状态维护

    CR-LSP建立完成后,RSVP-TE仍会发送信令消息对各个节点上的路径状态进行维护。

  • 错误通告

    RSVP节点在路径的建立和维护过程中发生消息处理错误时或故障时,会向上下游节点通告发生的错误。

  • 路径拆除

    拆除CR-LSP,并释放CR-LSP沿途节点的标签资源及带宽资源。与路径建立类似,路径拆除也是由入节点发起的。

动态CR-LSP的建立

动态CR-LSP的建立主要分为入节点向出节点发送Path消息和出节点向入节点发送Resv消息。Path消息用于创建RSVP会话和关联路径状态,发送时途经的节点上会建立路径状态块PSB(Path State Block)。Resv消息携带了资源预留信息,发送时途经的节点会建立资源预留状态块RSB(Reservation State Block)和分配标签。

下面详细介绍RSVP-TE建立CR-LSP的过程,如图5-16

图5-16  建立CR-LSP
  1. PE1触发CSPF计算从PE1到PE2的路径,这条路径是指定了沿途每一跳的IP地址。PE1将CSPF计算出来的IP地址列表作为显式路径对象ERO(Explicit Route Object)的内容,构造Path消息,并根据Path消息构造PSB,然后根据ERO将Path消息发送给P1,Path消息携带的内容如表5-5

    表5-5  PE1节点Path消息
    Object Value
    SESSION Source:PE1-if1;Destination:PE2-if0
    RSVP_HOP PE1-if1
    EXPLICIT_ROUTE P1-if0;P2-if0;PE2-if0
    LABEL LABEL_REQUEST
  2. P1收到PE1的Path消息,解析报文,根据Path消息构造PSB。然后P1更新Path消息,根据ERO将Path消息发送给P2,Path消息携带的内容如表5-6

    • 与PE1更新Path消息的RSVP_HOP为PE1到P1的出接口地址类似,P1更新Path消息的RSVP_HOP为P1到P2的出接口地址。

    • P1更新Path消息的ERO,删除P1自己的出、入接口地址及LSR ID。

    表5-6  P1节点Path消息
    Object Value
    SESSION Source:PE1-if1;Destination:PE2-if0
    RSVP_HOP P1-if1
    EXPLICIT_ROUTE P2-if0;PE2-if0
    LABEL LABEL_REQUEST
  3. P2收到P1的Path消息,与P1类似的处理,根据Path消息创建PSB,并更新Path消息,根据ERO将Path消息发送给PE2,Path消息携带的内容如表5-7

    表5-7  P2节点Path消息
    Object Value
    SESSION Source:PE1-if1;Destination:PE2-if0
    RSVP_HOP P2-if1
    EXPLICIT_ROUTE PE2-if0
    LABEL LABEL_REQUEST
  4. PE2收到Path消息后,从Session对象的Destination内容获知自己为待建立的CR-LSP的Egress节点。此时,PE2分配标签和资源,根据本地PSB产生Resv消息。Resv消息被发送给P2,该消息携带了PE2分配给P2的标签。

    PE2从收到的Path消息中提取RSVP_HOP字段的地址作为Resv消息的目的IP地址。此外,Resv消息沿着反向路径进行转发,因此Resv消息中并不携带ERO,消息携带的内容如表5-8
    说明:

    Resv消息如果包含RESV_CONFIRM对象,接收该消息的节点需要向发送该消息的节点发送ResvConf消息来确认资源预留请求。

    表5-8  PE2节点Resv消息
    Object Value
    SESSION Source:PE2-if0;Destination:PE1-if1
    RSVP_HOP PE2-if0
    LABEL 3
    RECORD_ROUTE PE2-if0
  5. 当P2收到Resv消息时,记录相关信息到RSB中,并分配一个新标签,更新Resv消息发给P1,Resv消息携带的内容如表5-9

    表5-9  P2节点Resv消息
    Object Value
    SESSION Source:PE2-if0;Destination:PE1-if1
    RSVP_HOP P2-if0
    LABEL 17
    RECORD_ROUTE P2-if0;PE2-if0
  6. 当P1收到P2的Resv消息时,同P2一样,记录相关信息到RSB中,并分配一个新标签,更新Resv消息发给PE1,Resv消息携带的内容如表5-10

    PE1收到Resv消息,获得P1分配的标签,表明资源预留成功,此时CR-LSP建立成功。

    表5-10  P1节点Resv消息
    Object Value
    SESSION Source:PE2-if0;Destination:PE1-if1
    RSVP_HOP P1-if0
    LABEL 18
    RECORD_ROUTE P1-if0;P2-if0;PE2-if0

动态CR-LSP的维护

路径状态维护

软状态

软状态是指在RSVP-TE中,通过RSVP消息的定时刷新来维持节点上的资源预留状态。

资源预留状态包括路径状态(path state)和预留状态(reservation state)。这两种状态分别由Path消息和Resv消息创建并定时刷新,将定时刷新时发送的Path消息和Resv消息统称为RSVP Refresh消息。RSVP Refresh消息用于在RSVP邻居节点进行状态同步,消息内容分别包含路径状态块和预留状态块。对于路径状态或者预留状态,如果连续一段时间没有收到刷新消息,这个状态将被删除。

RSVP Refresh

RSVP消息是以IP数据报的形式传输的,因此RSVP消息的传输是不可靠的。在CR-LSP建立后,通过软状态机制同步RSVP邻居节点的状态(包括PSB和RSB),各节点仍然会周期性的向上下游邻居节点发送RSVP Refresh消息。

Refresh消息并不是一种新的消息,它是以前发布过的消息的再次传送。刷新周期即为消息的Time Value字段指定的时间间隔。

对于某个状态,如果在指定刷新周期内没有收到刷新消息,这个状态将被删除。

相邻节点间发送的Path和Resv消息在时间上无先后顺序关系。

RSVP Srefresh

RSVP Refresh消息除了可以进行节点间状态同步之外,还可以检测各邻居间的可达性,维护RSVP节点之间的邻居关系。但是这种“软状态”机制所采用的Path消息和Resv消息的报文长度较大,当建立的CR-LSP很多时会过多的占用网络带宽资源。RSVP摘要刷新可以解决这个问题。

RSVP摘要刷新是通过在原有RSVP协议中定义新的对象来实现的,其具体实现原理如下:
  • Message_ID扩展和重传机制

    Message_ID扩展机制是在RSVP消息中携带扩展的对象。其中,Message_ID和Message_ID_ACK对象用于RSVP消息确认,从而提高RSVP消息的可靠性。

    使用Message_ID扩展对象还可实现RSVP重传机制。节点发送携带Message_ID的RSVP消息后初始化重传时间(假设为Rf秒)。如果在Rf时间间隔内没有收到ACK消息,经过(1+Delta)×Rf后,将重传此消息。Delta取决于发送方增加重传间隔的速率。重传将一直持续,直到收到一个确认消息或重传次数达到允许的最大限制值(称为重传增量)。

  • 摘要刷新Srefresh(Summary Refresh)

    摘要刷新可以不传送标准的Path或Resv消息,而仍能实现对RSVP状态的刷新。使用摘要刷新的好处是它减少了维持RSVP状态所需传输及处理的信息量。使用Srefresh消息更新RSVP状态时,常规的刷新消息将被抑制。

    摘要刷新消息承载了一系列Message_ID对象,用于识别需要被刷新的Path及Resv状态。摘要刷新需要与Message_ID扩展配合使用。只有那些已经包含Message_ID的Path和Resv消息发布过的状态才能使用摘要刷新机制刷新。

    当节点接收到一条摘要刷新消息时,与本地状态块(PSB或RSB)进行匹配。如果匹配,就更新本地状态,就像接收到一个标准的RSVP刷新消息一样;如果不匹配,节点将发送一个NACK消息来通知摘要刷新消息的发送者,并根据Path或Resv消息刷新相应的PSB或RSB,同时更新Message_ID。

    Message_ID对象中包含了Message_ID序列号。当LSP发生变化时,相应的Message_ID序列号增大。节点收到Path消息时,将其中的Message_ID序列号与本地状态块中保存的Message_ID序列号比较:如果相等,则保持状态不变;如果大于,则表示状态已更新。

错误通告
RSVP-TE依靠以下两种类型消息进行LSP的错误通告:
  • PathErr消息:RSVP节点在处理Path消息的时候,如果发生错误,就向上游发送PathErr消息。中间节点收到PathErr消息后,继续向上游转发,直至入节点。

  • ResvErr消息:RSVP节点在处理Resv消息时,如果发生错误,就向下游发送ResvErr消息。中间节点收到ResvErr消息后,继续向下游转发消息,直至出节点。

路径拆除

入节点在收到用户的删除LSP的命令或者PathErr消息后,会立即向下游发送PathTear消息通告下游节点拆除路径,下游节点收到此消息后会回复ResvTear消息给上游节点并拆除路径。

其中:
  • PathTear消息:用来删除节点路径信息,其作用与Path消息相反。

  • ResvTear消息:用来删除节点预留状态,其作用与Resv消息相反。

RSVP-TE消息

RSVP-TE消息用于MPLS TE实现过程中节点之间的信息交互。

RSVP消息格式

RSVP各类消息都包含一个通用头部,随后是多个可变长度、类型的消息对象,如图5-17

图5-17  RSVP消息格式

各字段的解释请参见表5-11

表5-11  RSVP消息格式描述

字段

长度

描述

版本号

4比特

表示RSVP协议版本号,目前值为1。

标识位

4比特

标识位,一般值为0。RFC2961扩展其用来标识是否支持摘要刷新(Srefresh)。如果支持Srefresh,则Flags置为0x01。

消息类型

8比特

表示RSVP消息类型。例如,1表示Path消息,2表示Resv消息。

校验和

16比特

表示RSVP的校验和。如果值为0,表示消息传输过程中不进行检验和检查。

TTL值

8比特

消息的TTL值。当节点接收到RSVP消息时,通过比较Send_TTL和IP首部的TTL值可以计算出该报文在非RSVP域中经过的跳数。

保留

8比特

保留。

RSVP消息总长度

16比特

表示RSVP消息的总长度,以字节为单位。

消息对象

可变

消息对象,每个RSVP消息都包含多个对象。不同类型的消息,包含的对象不同。

对象总长度

16比特

表示对象的总长度,以字节为单位。Length必须是4的倍数,最小值为4。

对象类

8比特

对象类。每个对象类都有一个名称,如SESSION、SENDER_TEMPLATE、TIME_VALUE。

对象类型

8比特

对象类型,表示同一类对象中不同的类型。Class_Number与C-Type唯一标识了一个对象。

对象内容

可变

对象内容,可变长度。

Path消息

RSVP-TE中,Path消息用于创建RSVP会话和关联路径状态。Path消息是从Ingress节点沿着数据流方向发送到Egress节点,途经的节点上会建立路径状态块PSB(Path State Block)。

Path消息IP源地址是入节点的LSR ID,目的地址是出节点的LSR ID。

表5-12列出了包含在Path消息中的一些对象。

表5-12  Path消息对象

消息对象

对象类

对象类型

对象内容

SESSION

1

1

RSVP会话相关信息,包括:Destination Address、Tunnel ID、Extend Tunnel ID。

RSVP_HOP

3

1

发送Path消息的上一跳的出接口地址和接口索引。

TIME_VALUE

5

1

包含消息的刷新时间值。

SENDER_TEMPLATE

11

1

指定了发送节点的IP地址和LSP ID。

SENDER_TSPEC

12

2

指明了数据流的流量特征。

LABEL_REQUEST

19

1

标签请求对象,只在Path消息中携带。

ADSPEC

13

2

用于收集路径上的实际QoS相关参数,例如,路径带宽估计、最小路径时延、Path MTU。

EXPLICIT_ROUTE

20

1

ERO,描述LSP经过的路径信息,可以是严格显式路径也可以是松散显式路径。Path消息沿ERO指定的路径转发,不受IGP最短路径约束。

RECORD_ROUTE

21

1

RRO,Path消息实际途经的LSR的列表。RRO可用于收集实际的路径信息,发现路由环路,还可以被复制到下一条Path消息中以实现路径锁定

SESSION_ATTRIBUTE

207

  • 1:LSP_TUNNEL_RA
  • 7:LSP Tunnel

指定了建立优先级、保持优先级、资源预留风格、亲和属性等属性。

Resv消息

当Egress节点收到Path消息时,将发送一个Resv消息作为回应。Resv消息携带了资源预留信息,从Egress节点逐跳发送给前一跳节点。沿途的每个节点会创建和维护资源预留状态块RSB(Reserved State Block)并分配标签。当Resv消息到达Ingress时,一条LSP就建立成功了。

表5-13列出了包含在Resv消息中的一些对象。

表5-13  Resv消息对象

消息对象

对象类

对象类型

对象内容

INTEGRITY

4

1

包含RSVP消息的认证密钥。

SESSION

1

1

包含了RSVP会话相关信息,如Destination Address、Tunnel ID、Extend Tunnel ID。

RSVP_HOP

3

1

包含发送Resv消息出接口IP地址和接口索引。

TIME_VALUE

5

1

包含消息的刷新时间值。默认值为30秒。

STYLE

8

1

资源预留风格,由Ingress节点指定。

FLOW_SPEC

9

  • 1:Reserved (obsolete) flowspec object
  • 2:Inv-serv flowspec object

指明了数据流的QoS特征。

FILTER_SPEC

10

1

发送节点的IP地址和LSP ID。

RECORD_ROUTE

21

1

RRO,沿途收集的各节点的入接口IP地址、LSR-ID和出接口IP地址。

LABEL

16

1

分配的标签。

RESV_CONFIRM

15

1

预留确认请求,携带了请求预留确认的节点的IP地址。

RSVP资源预留风格

资源预留风格是指RSVP节点处理上游节点的资源预留请求时的资源预留方式。常用的预留风格有:

  • 固定过滤风格FF(Fixed Filter):为每个资源预留请求的发送者创建单独的预留,该预留不与其他发送者共享。即同一链路的不同CR-LSP有不同的资源预留。

  • 共享过滤风格SE(Shared Explicit):建立单一的资源预留。该预留允许指定的一系列发送者共享。即同一链路的不同CR-LSP共享一个资源预留。

翻译
下载文档
更新时间:2019-08-20

文档编号:EDOC1000141521

浏览量:8177

下载量:343

平均得分:
本文档适用于这些产品
相关文档
相关版本
Share
上一页 下一页