亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: 學(xué)習(xí)RSVP-TE一點(diǎn)筆記(算不上筆記)[4] [打印本頁]

作者: ilex    時間: 2007-09-26 00:15
標(biāo)題: 學(xué)習(xí)RSVP-TE一點(diǎn)筆記(算不上筆記)[4]

3. LSP Tunnel related Message Formats
   //LSP隧道相關(guān)消息格式
   
   Five new objects are defined in this section:
      Object name          Applicable RSVP messages
      ---------------      ------------------------
      LABEL_REQUEST          Path
      LABEL                  Resv
      EXPLICIT_ROUTE         Path
      RECORD_ROUTE           Path, Resv
      SESSION_ATTRIBUTE      Path
   New C-Types are also assigned for the SESSION, SENDER_TEMPLATE, and
   FILTER_SPEC, objects.
   Detailed descriptions of the new objects are given in later sections.
   All new objects are OPTIONAL with respect to RSVP.  An implementation
   can choose to support a subset of objects.  However, the
   LABEL_REQUEST and LABEL objects are mandatory with respect to this
   specification.
   //對以上新對象的描述,將在后續(xù)章節(jié)中給出。這些新對象對RSVP都是可選的。
   //一個實(shí)現(xiàn)可以選擇支持這些對象的子集。此外,LABEL_REQUEST和LABEL對象
   //對本文檔(或RSVP-TE)而言是必須支持的。
   The LABEL and RECORD_ROUTE objects, are sender specific.  In Resv
   messages they MUST appear after the associated FILTER_SPEC and prior
   to any subsequent FILTER_SPEC.
   //LABEL和RRO對象,與sender有關(guān)。它們必須出現(xiàn)在相關(guān)的FILTER_SPEC對象后
   //且在其他FILTER_SPEC對象之前,當(dāng)然,是在RESV消息中。
   The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST, and
   SESSION_ATTRIBUTE objects is simply a recommendation.  The ordering
   of these objects is not important, so an implementation MUST be
   prepared to accept objects in any order.
   //ERO,LABEL_REQUEST和SESSION_ATTRIBUTE的位置只是一個建議。這些對象的
   //順序不重要,因此一個實(shí)現(xiàn)必須準(zhǔn)備好以任何順序接收這些對象。
3.1. Path Message
   
   The format of the Path message is as follows:
   //PATH消息的格式如下:
   
       ::=        [  ]
                                
                              
                               [  ]
                              
                               [  ]

Awduche, et al.             Standards Track                    [Page 15]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001
                               [  ... ]
                              
       ::=   
                               [  ]
                               [  ]
3.2. Resv Message
   The format of the Resv message is as follows:
       ::=        [  ]
                                 
                              
                               [  ]  [  ]
                               [  ... ]
                                
       ::=
                               |
       ::=  
                                [  ]
                               |
                              
       ::= [  ]  
                               [  ]
       ::=  
       ::=
                               |  
       ::=       [  ]
      Note:  LABEL and RECORD_ROUTE (if present), are bound to the
             preceding FILTER_SPEC.  No more than one LABEL and/or
             RECORD_ROUTE may follow each FILTER_SPEC.
      //注意:如果有LABEL和RRO對象,一定要在FILTER_SPEC之后,如果存在,
      //每個FILTER_SPEC之后至多只有一個LABEL和RRO。
      
Awduche, et al.             Standards Track                    [Page 16]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001
4. LSP Tunnel related Objects
4.1. Label Object
   Labels MAY be carried in Resv messages.  For the FF and SE styles, a
   label is associated with each sender.  The label for a sender MUST
   immediately follow the FILTER_SPEC for that sender in the Resv
   message.
   //RESV消息中可能攜帶標(biāo)簽。對于FF和SE方式,每個sender關(guān)聯(lián)一個標(biāo)簽。與
   //sender有關(guān)的標(biāo)簽必須緊跟在描述該sender的FILTER_SPEC之后,當(dāng)然,此
   //處說的是RESV消息。
   
   The LABEL object has the following format:
   LABEL class = 16, C_Type = 1
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           (top label)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The contents of a LABEL is a single label, encoded in 4 octets.  Each
   generic MPLS label is an unsigned integer in the range 0 through
   1048575.  Generic MPLS labels and FR labels are encoded right aligned
   in 4 octets.  ATM labels are encoded with the VPI right justified in
   bits 0-15 and the VCI right justified in bits 16-31.
   //LABEL對象的內(nèi)容只是一個標(biāo)簽,由4個byte組成。
4.1.1. Handling Label Objects in Resv messages
   In MPLS a node may support multiple label spaces, perhaps associating
   a unique space with each incoming interface.  For the purposes of the
   following discussion, the term "same label" means the identical label
   value drawn from the identical label space.  Further, the following
   applies only to unicast sessions.
   //一個MPLS節(jié)點(diǎn)可能支持多重的標(biāo)簽空間,可能把每個入接口關(guān)聯(lián)一個唯一的
   //空間。一下討論中,"相同標(biāo)簽"表示同一個標(biāo)簽空間內(nèi)的同一標(biāo)簽值。另外,
   //只應(yīng)用于單播會話。
   Labels received in Resv messages on different interfaces are always
   considered to be different even if the label value is the same.
   //不同接口接受的RESV消息,盡管他們可能標(biāo)簽值相同,但是通常認(rèn)為是不同
   //的標(biāo)簽。(每個接口有其獨(dú)自的標(biāo)簽空間)
4.1.1.1. Downstream
   The downstream node selects a label to represent the flow.  If a
   label range has been specified in the label request, the label MUST
   be drawn from that range.  If no label is available the node sends a
   PathErr message with an error code of "routing problem" and an error
   value of "label allocation failure".
   //下游節(jié)點(diǎn)選擇一個標(biāo)簽以描述該流量。如果在Label request中限定了標(biāo)簽
   //范圍(label request在PATH中),標(biāo)簽必須在該范圍內(nèi)分配。如果無合適標(biāo)簽
   //可用,該節(jié)點(diǎn)發(fā)送一個錯誤碼為"routing problem",錯誤值為"label
   //allocation failure"的PATHERR消息。
   If a node receives a Resv message that has assigned the same label
   value to multiple senders, then that node MAY also assign a single
   value to those same senders or to any subset of those senders.  Note
   //如果節(jié)點(diǎn)收到的RESV消息中,給多個sender分配了相同的標(biāo)簽,那么它可能
   //給這些sender(或任意sender的子集)只分配一個標(biāo)簽。

Awduche, et al.             Standards Track                    [Page 17]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001
   that if a node intends to police individual senders to a session, it
   MUST assign unique labels to those senders.
   //如果節(jié)點(diǎn)
   In the case of ATM, one further condition applies.  Some ATM nodes
   are not capable of merging streams.  These nodes MAY indicate this by
   setting a bit in the label request to zero.  The M-bit in the
   LABEL_REQUEST object of C-Type 2, label request with ATM label range,
   serves this purpose.  The M-bit SHOULD be set by nodes which are
   merge capable.  If for any senders the M-bit is not set, the
   downstream node MUST assign unique labels to those senders.
   //如果是ATM,一個深層的問題需要考慮。某些ATM節(jié)點(diǎn)不能合并stream。這些
   //節(jié)點(diǎn)可能(可以)設(shè)置label request中的一個bit為0以標(biāo)識。C-Type為2的
   //LABEL_REQUEST的M-bit,label request且附帶ATM標(biāo)簽范圍,服務(wù)于該用途(嘔)
   //那些沒有設(shè)置M-bit的sender,下游節(jié)點(diǎn)必須分配唯一一個標(biāo)簽給這些sender。
   Once a label is allocated, the node formats a new LABEL object.  The
   node then sends the new LABEL object as part of the Resv message to
   the previous hop.  The node SHOULD be prepared to forward packets
   carrying the assigned label prior to sending the Resv message.  The
   LABEL object SHOULD be kept in the Reservation State Block.  It is
   then used in the next Resv refresh event for formatting the Resv
   message.
   //一旦分配好標(biāo)簽,節(jié)點(diǎn)構(gòu)造一個新的LABEL對象。該節(jié)點(diǎn)把該LABEL對象作為
   //RESV消息的一部分發(fā)送給PHOP(上一跳)。該節(jié)點(diǎn)應(yīng)該準(zhǔn)備好轉(zhuǎn)發(fā)那些打了(發(fā)
   //往上游的RESV中的)標(biāo)簽的數(shù)據(jù)包。該LABEL對象應(yīng)該保存在RSB中。用于下次
   //RESV刷新時,解析該RESV消息。
   A node is expected to send a Resv message before its refresh timers
   expire if the contents of the LABEL object change.
   //如果LABEL對象改變,節(jié)點(diǎn)應(yīng)該在刷新定時器到期前發(fā)送RESV消息。
4.1.1.2. Upstream
   A node uses the label carried in the LABEL object as the outgoing
   label associated with the sender.  The router allocates a new label
   and binds it to the incoming interface of this session/sender.  This
   is the same interface that the router uses to forward Resv messages
   to the previous hops.
   //節(jié)點(diǎn)使用收到的LABEL對象中的標(biāo)簽作為與sender關(guān)聯(lián)的出標(biāo)簽。該節(jié)點(diǎn)為
   //該會話/sender分配一個新標(biāo)簽并且與入接口綁定。該接口與發(fā)送RESV消息
   //的接口相同。
   Several circumstance can lead to an unacceptable label.
   //某些情況可能導(dǎo)致一個不可接受的標(biāo)簽。
      1. the node is a merge incapable ATM switch but the downstream
         node has assigned the same label to two senders
      //1.
      2. The implicit null label was assigned, but the node is not
         capable of doing a penultimate pop for the associated L3PID
      3. The assigned label is outside the requested label range
      //3.標(biāo)簽在請求的標(biāo)簽范圍之外。
   In any of these events the node send a ResvErr message with an error
   code of "routing problem" and an error value of "unacceptable label
   value".
   //以上任何情況發(fā)生,本節(jié)點(diǎn)發(fā)送一個錯誤碼為"routing problem錯誤值為
   //"unacceptable label value"的RESVERR消息。



Awduche, et al.             Standards Track                    [Page 18]

RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001
4.1.2. Non-support of the Label Object
   Under normal circumstances, a node should never receive a LABEL
   object in a Resv message unless it had included a LABEL_REQUEST
   object in the corresponding Path message.  However, an RSVP router
   that does not recognize the LABEL object sends a ResvErr with the
   error code "Unknown object class" toward the receiver.  This causes
   the reservation to fail.
   //通常情況,如果節(jié)點(diǎn)在PATH中如果沒有攜帶LABEL_REQUEST對象,則收到的
   //RESV消息中不會攜帶LABEL對象。不支持LABEL對象RSVP節(jié)點(diǎn),發(fā)送一個錯誤
   //碼為"Unknown object class"的RESVERR給末節(jié)點(diǎn)。這將導(dǎo)致預(yù)留失敗。


本文來自ChinaUnix博客,如果查看原文請點(diǎn):http://blog.chinaunix.net/u/411/showart_389931.html




歡迎光臨 Chinaunix (http://72891.cn/) Powered by Discuz! X3.2