MX2007001425A - Forwarding of network traffic in respect of differentiated restricted transit network nodes - Google Patents

Abstract

There is provided a method of forwarding a traffic flow in a communications network having at least one network node for which network traffic is selectively prevented from transiting the network node. The method includes the step of selecting a specified category of network traffic that is to be prevented from transiting the network node. The method also includes the step of determining a path within the network for forwarding the traffic flow, whereby the network node is excluded for transit in establishing the path where the traffic flow is identified with the specified category of network traffic.

Description

TRANSMISSION OF NETWORK TRAFFIC WITH RESPECT TO DIFFERENTIATED NODES OF RESTRICTED TRANSIT NETWORK Field of the Invention The present invention relates, in a general manner, to the field of communications networks and more particularly refers to a method and apparatus for transmission or routing based on the policy or criteria of the message traffic with respect to of restricted traffic network nodes. By way of example, the invention could be specially adapted to routed source or source networks, such as those operating in accordance with the protocols of the Asynchronous Transfer Mode (ATM) or Multi-Protocol Label Switching. (MPLS, for its acronym in English). According to the invention, policy-based transmission of network traffic is used in conjunction with restricted traffic transmission in order to provide traffic flows, connections or calls, so that some flows, connections or predetermined calls of traffic , can be allowed to go through a network node regardless of their restricted transit status. As such, the restricted traffic state of the network node in question differs between some flows, connections or traffic calls and not between others, with the result that the state of restricted transit of the node could be forced or ignored in a REF manner. 179273 selective Background of the Invention It is known in the field of communications networks to configure network nodes as restricted transit nodes. Namely, it is known to restrict the traffic of network traffic through specific nodes of a network in order to prevent this traffic, or the connections related thereto, from crossing one or more network nodes. Commonly, provisioning of restricted traffic status with respect to a network node could prohibit traffic or network connections from passing through the node, although it could allow traffic or connections to originate or terminate at this node. In the known mechanisms of restricted transit, during the time in which a network node has been designated as a restricted transit node, no traffic is ordinarily allowed to transit the node. On the other hand, while a network node is not designed as a restricted transit node, all traffic is normally allowed to transit the node. In contrast to restricted transit routing, policy routing or criteria is used in the technique of communication networks in order to control the way in which network traffic or its related traffic connections are routed through a routing domain of the network. A known routing specification and. signage for policy routing support is provided through the specification of the ATM Forum Technical Committee entitled "Policy Routing", version 1.0, which is dated April 2003 and is identified as the document number af- Cs-0195.000 (the "Policy Routing Specification"), the contents of which are incorporated herein by reference. The Policy Routing Specification is a complement to the existing signaling specifications of the ATM Forum Technical Committee, namely: "ATM User-Network Interface (UNI) Signaling Specification", version 4.1, which is dated April 2002 and is identified as the document number af-sig-0061.002; "ATM Inter-Network Interface Specification", version 1.1 / which is dated September 2002 and is identified as document number af-cs-0125.002; and "Prívate Network-Network Interface Specification", version 1.1, which is dated April 2002 and is identified as the document number af-pnni-0055.002, all of which are known to those persons skilled in the art of communications networks . In the normal policy routing mechanisms, and as described in the Policy Routing Specification, Network Elements ("Ne") or Resource partitions ("Rp") could be identified and advertised (propagated) through the network topology for purposes of routing traffic through the network in question. For example, a network element could be a link or the whole of a common (telephone) link group while a resource partition could be a bandwidth partition of this common link group. In the transmission of a traffic flow, the request based on the policy for transmission or criteria could be made, where the request could describe a transmission restriction, either to (i) prescribe the evasion or requirement of one or more particular network elements, or (ii) prescribe the requirement of one or more particular partitions of resources. This request based on the policy could be communicated through the restriction of the transmission, such as a policy restriction that is being assigned to a connection and signaled during the establishment of the same. A node that is initiating the establishment of the network path for a traffic flow will use the advertised (propagated) network elements and the resource partitions together with the flagged policy restriction to calculate or otherwise establish a path of network access that satisfies the restriction in question. Policy routing capabilities could be used in communication networks to provide variable services based on different network utilization strategies. For example, policy routing could be deployed in the provisioning of the Principal Virtual Networks ("VBN"), in the selection or cancellation of the network access paths associated with the predetermined quality of the link, in the routing of connections using multiple-order policy constraints, in the specification and use of core network resources for central interconnection networks, in the bandwidth partition between the SVC and SPVC connections, and in the dynamic distribution of network bandwidth between the identifiable categories of connections. However, the use of policy routing in conjunction with the restricted transit capacity has not been known, so that the latter can be activated or deactivated. in predetermined instances based on a specific policy.

SUMMARY OF THE INVENTION In accordance with a broad aspect of the present invention, there is provided a method of transmitting a traffic flow in a communication network having at least one network node thereof for which the network traffic is avoided, in a selective way, that transites the same, the method comprises the steps of: (a) selecting a specific category of network traffic that will be prevented from traveling the network node; and (b) determining an access path within the network for the transmission of the traffic flow, where the network node is excluded that transits in the establishment of the access path, where the traffic flow is identified with the specific category of network traffic.

Brief Description of the Figures By way of illustration and not limitation, the embodiments of the present invention are described below with reference to the following figures, in which: Figure 1 illustrates a routed network of example origin showing the technique of the prior art of restricted transit routing; Figure 2 represents a routed network of example origin in which one embodiment of the present invention could be deployed for the provision of restricted transit restricted transmission; and Figures 3-6 show alternative formats for a message that could be used according to other embodiments of the present invention for the purpose of announcing or propagating the differentiated transmission capacity of transit. restricted from a network node.

Detailed Description of the Invention With reference to Figure 1, a known mechanism for restricted transit routing is shown in the context of a routed network of example origin 10 operating in accordance with the PNNI protocol. The network nodes 12 of the network 10, each of which is denoted as the nodes A, are access nodes. The network nodes 14 thereof are central nodes and these are denoted as the nodes C. The different network nodes 12 and 14 of the network 10 are interconnected through the links 16 as are known to those skilled in the art. . According to known traffic routing techniques, the provision of the network 10 is possible, so that network traffic nodes 12 do not transit any network traffic. This traffic can be routed through connections 18 or 20, which terminate, respectively, in a network node 12 or originate with it. Other network traffic that does not terminate at or originate with a network access node 12, for example, a connection as in 22 from a central network node 14 to another central network node 14, is denied or rejected to routing through a network access node, if this node was provided or activated for routing restricted traffic. The connection as in 22 has been represented with an "X", to denote that this is rejected in the particular example mentioned above. With reference to Figure 2, a method according to an embodiment of the present invention is described with reference to a network 30, which illustrates an example that allows, selectively, certain categories of flows, connections or traffic calls cross the nodes of restricted traffic, as well as, selectively, allows flows, connections or traffic calls that belong to certain Primary Virtual Networks ("VBN"). Those skilled in the art should be prepared to appreciate that the present invention could be adapted to be applied in any identifiable category or collection of flows, connections or traffic calls. The network 30 could be, for example, a routed source network operating in accordance with the PNNI protocol. The network 30 has three edges or network access nodes 12a, 12b and 12c, which are denoted, respectively, as A.l, A.2 and A.3. In addition, the central network nodes 14a, 14b, 14c and 14d are additionally denoted as Cl, C.2, C3 and C.4, which are interconnected by means of the links 16 'to each other and to one another. or more network access nodes Al, A.2 and A.3 in the manner known in this art. The network nodes A.l, A.2 and A.3 are all restricted transit nodes, in the previously defined sense, for illustration purposes. In network 30, the mixed connections SPVC and SVC could be routed therein and if desired, the method and apparatus of the present invention could be deployed to allow a category of these connections to cross a transit node otherwise restricted. , while not allowing the other category of these connections to do it this way. For example, because the SVC connections might normally be shorter in duration and more dynamic than the SPVC connections, the bandwidth inversion of the SVC connection is much higher than that of the SPVC connections. As a result, this is not an uncommon network provisioning scheme to ensure that there is sufficient bandwidth available for longer duration SPVC connections that must originate and end at a particular node, while establishing some bandwidth for SVC calls of generally shorter duration. As a result of differences in bandwidth distribution and expected duration of SPVC versus SVC connections, it might be desirable to allow SVC connections to pass through access nodes Al, A.2 and A.3 if necessary, and that SPVC connections were not allowed to pass through these same nodes because the bandwidth would be consumed for a long period of time and this could not be originally planned for this node. With the current capacity of restricted transit routing, all calls would be allowed to transit or restricted from transit to access nodes A.l, A.2 and A3. Therefore, according to the prior art techniques, the permission would not be known that only the SVC connections pass through a restricted transit node but the SPVC connections would still be restricted from doing so. However, in the example of the network 30, the SVC connections as in 32 are allowed to traverse the network access node Al, regardless of the state of the restricted transit thereof, while only the SPVC connections of origin and termination. as in 33 and 35, they are allowed to transit, respectively, to and from the network access node Al Similarly, in the case of the Primary Virtual Networks, it may be desirable for engineering or traffic design purposes or for security or call control reasons that the connections of a VBN are allowed to traverse a restricted transit node while do not allow the connections of another VBN to do it this way. Therefore, it could be considered desirable if connections through a first VBN, namely VBN A, were allowed to transit only in the network access nodes A.l and A.3, regardless of the restricted transit status of those network nodes. This is shown through the VBN connections A, as in 34 and as in 38, which traverse the respective network nodes A.l and A.3. In the case of connections through a second VBN, namely VBN B, it could be considered desirable if the connections through this VBN were allowed to transit only the network access nodes A.2 and A.3, as an exception to the transit state otherwise restricted from those network nodes. This is shown through the VBN B connections, as in 36 and as in 40, which traverse the respective network nodes A.2 and A.3. In general, by allowing some predetermined traffic flows, connections or calls to pass through a restricted traffic node while restricting all others to do so in this way, it can be expected to help with capacity planning of network resources . However, the problem with existing restricted traffic routing is that it is only applicable based on a nodal and does not allow the restricted traffic state of a node to be applied in some traffic flows and not in others. In one embodiment of the method of the present invention, an exemplary implementation of the invention is described once more with reference to Figure 2. Although this implementation is performed specifically in the PNNI protocol, those skilled in the art will understand that the invention is capable of being implemented in other current or future interconnection protocols, for example, in the TP, MPLS, OSPF, GMPLS or IS-IS protocols, to name but a few examples . In the PNNI protocol a new type-length-value ("TLV") field could be created in the Nodal Information Group ("IG") that is used in the known PNNI announcement messages. In the known restricted traffic routing, the restricted transit state of a network node is advertised or propagated using a bit or single bit in the nodal IG. This bit in the prior art indicates whether the restricted transit state of a network node to which the IG belongs is either activated or deactivated. According to one embodiment of the invention, the new TLV field identifies the flows, connections or traffic calls that could be defined to recognize and comply with the restricted transit state activated or deactivated of the particular network node announcing the TLV, or instead, it could be defined to recognize and override the restricted transit state activated or deactivated from the node. The definitions in question could be made by means of known policy routing labels, if desired, and this is described in more detail later. The announcement of the TLV field as modified according to the modality mentioned with Priority, it will allow other network nodes to generate access routes for flows, connections or traffic calls based on the policy or criteria that are identified in the TLV field that take into account the differentiated status of the restricted traffic of the announcement node. The different categories of flows, connections or traffic calls identified by means of known policy routing labels in the new TLV field mentioned above can be carried out in a way that corresponds to policy restrictions that will be required through these flows, connections or traffic calls. For example, a VBN A call may be made to require a policy restriction to be taken along a different access path than a VBN B call. Similarly, an SVC call may be made to require a restriction. of policy that will lead it through nodes or partitions different from those for a call SPVC. Still with respect to Figure 2, if it were desirable for an Al network node to restrict the transit of all connections other than SVC calls or VBN A calls, the Al node could announce or propagate a nodal IG at its end nodes. or network connection 30 containing a TLV field indicating that the restricted transit state of the Al node will be applied on this node in all policy routing labels different from those of the policy restrictions associated with SVC calls or with VBN A calls. For example, the policy routing tag Pl could refer to SPVC calls and the policy routing tag P2 could refer to SVC calls. For VBN identification, the P3 policy routing label could refer to the VBN A calls as in 34 and 38 and the policy routing label P4 could refer to the VBN B calls such as in 36 and 40. Therefore , in the given example, the nodal IG of an Al network node could indicate by means of its TLV field as mentioned above that the activated state of restricted transit of the node is applied in all connections different from those with associated restrictions of policy that contains the policy routing labels P2 and P3. This notice of the restricted traffic state that is differentiated could be made if desired by indicating the policy routing labels P2 and P3 as exceptions for the activated traffic restricted state of the node or alternatively, indicating the policy routing labels Pl and P4 that define the prohibited connections of the restricted transit state in question. Based on the example given above, the result in any case is that only traffic flows 32 and 34 would be allowed to transit the Al node, with these traffic flows referring, respectively, to the SVC calls and the VBN A calls. Similarly to the A2 network node, its nodal IG could announce that only the calls based in policy with policy restrictions that contain the P4 policy routing tag will go through the node. Again, the TLV field of the nodal IG of the network node A.2 could identify the policy routing tag P4 as an exception to the restricted traffic state of the node when the node is announcing that its restricted transit state is activated or alternatively, policy routing labels Pl, P2, and P3 may instead be listed to define prohibited connections for restricted transit purposes. In any case, the end result is that only VBN B calls would be allowed to transit node A.2 as in 36. Finally, it might be desirable for network node A.3 to only transit calls VBN A and VBN B, although not other calls within the network 30. In this example, the nodal IG of the network node A3 could identify both of the policy routing labels P3 and P4 that define the connections that will be allowed to transit node A.3 and therefore, they are exceptions to the restricted transit status of this node when it is activated. Instead, both of the Policy routing labels Pl and P2 could be used to define the prohibited connections for node A.3 where the restricted transit status of the node is activated by announcing only that policy routing labels Pl and P2 are restricted traffic and all other policy routing labels are not restricted traffic. Once again, the final result is that both of the calls VBN A and VBN B would be allowed to transit the node A3, respectively as in 38 and 40. Those skilled in this art will understand that any of the nodes Al, A .2 or A.3 could modify its IG node information at any desired time in order to announce a different policy based on routing criteria for the restricted traffic state of the nodes. For example, if the network node Al no longer had the capacity to allow SVC calls, then it could announce that a nodal IG with a TLV field no longer indicates the policy routing tag P2 as an exception to the activated state restricted traffic routing or with a TLV field that would recently indicate the policy routing label P2 as a prohibited policy for the purpose of the restricted traffic routing enabled state with respect to the Al node. Figures 3, 4 and 5 illustrate alternative formats for the IG node message of a network node announcing the Differentiated capacity of restricted transit at its end or network connection nodes according to the present invention. In Figure 3, the nodal IG message 50 contains a restricted traffic warning 52 which denotes whether the restricted traffic state of the node is activated or deactivated. A TLV field A in the form of the restricted traffic exception list 54, denoted as "EX LIST", is also part of the Nodal 50 IG message. The restricted traffic exception list 54 could list the policy routing labels associated with the flows, connections or traffic calls that will be allowed to transit the announcement node when the restricted transit notice indicates that the restricted transit status is activated. In this case, any path establishment request based on the policy that identifies any one of the flows, connections or traffic calls of the exception list 54 by means of the associated policy routing labels will be allowed in the node of announcement. This is described in further detail below. According to one embodiment of the present invention as illustrated in Figure 3, the exception list 54 as described above could be in the form of a Network Element ("Ne") identifier list coupled with a list of Resource Partition Identifier ("Rp"). For example, the identifier list Ne could contain the Network Service Category ("NSC") labels Nei, Ne2, ... Nen, while the Rp identifier list could contain the NSC tags Rpi, Rp2, ... Rpn. This could be summarized as follows: Ne-NSC list (Nei, Ne2, ... Ne ") (1) Rp-NSC list (Rpi, Rp2, ... Rpn) (2) Previous labels NSC are as defined in the Policy Routing Specification, referred to above. Where the restricted transit notice 52 as indicated above that the restricted transit state is activated, the exception list 54 originally reflected in the form of the above coupled lists (1) and (2) may be further combined to form a unique exception element in a logical form and as follows:. { Nei, Ne2, ... Nen and Rpi and Rp2 and ... Rpn} (3) As is known to those skilled in the art, a call or connection policy that is signaled in accordance with the Policy Routing Specification may have multiple criteria or policy elements associated therewith. These policy elements are groupings of policy routing labels. As explained in more detail below, where a policy-based call requires through any one of its policy signal elements any combination or subset of the NSC tags found in the previous exception element (3), then, the call or connection in question will be allowed to transit the network node that is announcing the identifier list Ne (1) and the identifier list Rp (2). Where none of the policy elements of the flagged policy requires any combination or subset of the elements or NSC tags of the exception element (3), then the call or connection in question can not be routed through the network node. If the flagged policy in question met the Policy Routing Specification, the policy elements of the flagged policy would first be derived through a logical expansion process before making the stated determination as to whether the call or connection in question The network node announcing its restricted transit restricted state according to the present invention will be allowed to transit. This process of logical expansion is explained in further detail below. Instead, the exception list 54, may or additionally, lists the policy routing labels associated with traffic flows, connections or calls that will be prohibited when the restricted transit notice indicates that the restricted transit status is disabled. In this case, it will not be allowed in the node announced any path establishment request based on the policy whose policy elements, each one identifies either one of the flows, connections or traffic calls of the exception list 54 by means of its policy routing labels. This is addressed in more detail below. Where the restricted traffic notice as indicated above in which the restricted transit state is deactivated, the exception list 54 in the form of the above lists (1) and (2) can be combined to form a sequence of exception elements in logical form or and individualized exception elements, as follows:. { Nei } or { Ne2 } or ... { Nen } or { Rpi} or { Rp2} or ... { RPn} (4) As explained in more detail below, where any one or more of the NSC labels of the individualized elements of the previous exception (4) is contained by or consists of each and every one of the flagged elements of the policy of a policy-based call, then, the call or connection in question will not be allowed to transit the network node that is advertising the identifier list Ne (1) and the identifier list Rp (2). The use of the term "content per" means transport in which the flagged element of policy comprises at least the individual element of exception in question (4). Pointed alternately, if at least one policy element of the policy-based call did not contain or consist of at least one of the NSC labels of the individualized exception elements (4), then the network node will allow the call or connection transit the node. As mentioned above, if the signaled policy in question complied with the Policy Routing Specification, the flagged policy elements of the flagged policy would first be derived through a process of logical expansion as described more fully below. . The above description in relation to the embodiment of Figure 3, refers to the use of the exception list 54 to identify the calls or connections that will be allowed or prohibited to transit in a network node in the context of a restricted transit state of the same that is activated or deactivated, will be further described in relation to the call or connection policies that follow the Policy Routing Specification mentioned above. The general format of a flagged policy, as known to those skilled in the art, could be represented as follows: Policy :: =. { [require (logical_or \ logical_and {Ne-NSC_list.}.; logical_or \ logical_and { Rp-NSC_list.}.); must-avoid (logical_or | logical_and {Ne-NSC_list.}.)]} (5) where: . { Ne-NSC list} is a list of NSC policy routing labels that refers to network elements; . { Rp-NS list} is a list of NSC policy routing labels that refers to resource partitions; the term "require" denotes a component of the policy that is a requirement for the routing of a call or connection associated with the flagged policy (5); the term "must-avoid" denotes a component of the policy that is required to be avoided from the routing of the call or connection associated with the flagged policy (5); and the terms "logical_or" and "logical_and" are alternative operators that denote, respectively, whether the constituent policy routing labels immediately result from the lists. { Ne-NSC list} or { Rp-NSC list} They will be either logically or and, or logically, and, as might be the case. It is also possible for either or both of the lists. { Ne-NSC list} Y . { Rp-NSC list} contain a unique policy routing label, in this case the operators "logical_or" and "logical_and" will not be used in these individual items. In addition, in the Policy Routing Specification, each of the items "require" the policy signaled (5) will be interpreted to be in logical form and and in relation to one with respect to the other. These "require" items are the constituent parts of the "require" component of the flagged policy (5) as explained below. The "require" component of the flagged policy (5), namely, the component consisting of: logical_or | logical_and. { Ne-NSC list}; logical_or | logical_and. { Rp-NSC list} (6) It can also be divided into smaller elements in the nature of the required policy elements. To provide a simple example of the mentioned expansion of the 'require' component (6), a policy is defined as: [require (logical_or { Nei, Ne2.}.)] (7) can be expanded to the required elements of politics (Nej.) and (Ne2), each of which is logically or and in relation to each other. In the same way, a policy is defined as: [require (logical_and { Nei, Ne2.}.)] (8) can be expanded to the required single policy element (Nei, and Ne2). Where more than one list of NSC policy routing labels is found in the 'require' component (6), the 'require' component (6) can be expanded through the logical multiplication of the lists. { Ne-NSC list} Y . { Rp-NSC list} , with each one resulting in the required element of policy that is logically or in relation to each other. By way of example, a policy is defined as: [require (logical_or { Nei, Ne2.}.; Logical_and { Rpi, Rp2.}.] (9) can be expanded into two required policy elements, to know, (Nei, and Rpi, and Rp2) and (Ne2 and Rpi and Rp2), with these two required elements of politics that are logically or and in relation to each other.For additional example, a policy is defined as: [require (logical_or { Nei, Ne2.}.; logical_or { Rpi, Rp2.}.] (10) can be expanded into four required policy elements, namely, (Nei and Rpi) (ei and RP2 ), (Ne2 and Rpi) and (Ne2 and Rp2), with these four required elements of politics that are logically or and in relation to each other.A similar analysis as outlined earlier could be used to expand the "avoid" component of the flagged policy (5), namely, the component consisting of: [must-avoid (logical_or | logical_and {Ne-NSC_list.}.] (11) However, in The embodiment of the present invention, which is illustrated in FIG. 'avoid' (11) of the flagged policy (5) is not used in order to compare the flagged policy (5) with the differentiated capacity of restricted traffic that is announced from the node in question in order to determine whether or not to route a call or connection that transits in the node. Once the signaled policy (5) has been expanded as previously mentioned in its required constituent policy elements, these required policy elements are used to compare the flagged policy (5) with the differentiated capacity of restricted transit that is announced. of the node in question, in the way explained previously. Next, with reference to another embodiment of the invention as illustrated in Figure 4, the nodal message IG 60 contains a warning 62 denoting whether the restricted traffic state of the node is activated or deactivated. A TLV field A in the form of a restricted traffic definition list 64, denoted as "DEF. LIST", is also part of the IG 60 nodal message. The restricted traffic definition list 64 could list the policy routing labels associated with the flows, connections or traffic calls that will be prohibited to transit in the announcement node when the restricted transit tag indicates that the restricted transit state is activated. In this case, any request for the establishment of a Policy-based access that identifies any one of the flows, connections or traffic calls from the definition list 64 by means of the associated policy routing labels will not be allowed in the advertised node. The definition list 64, could instead or additionally, list the policy labels associated with the flows, connections or traffic calls that will be allowed when the restricted traffic notice indicates that the restricted transit status is disabled. In this case, any policy-based path establishment request that identifies any one of the flows, connections, or traffic calls from the definition list 64 by means of its associated policy routing labels will be allowed in the advertised node . Those skilled in the art will appreciate that the analogous data structures in the above structures described in relation to the embodiment of Figure 3 could be used to create the restricted transit definition list 64, for example, by means of a list of Network Element Identifier ("Ne") with a list of Resource Partition Identifier ("Rp") as mentioned above. Also, the rules and techniques analogous to those described above could be used in order to compare a flagged policy with the transit definition list restricted 64 for the purpose of determining whether or not a call or connection will be transited through a node that is advertising a differentiated restricted transit capacity. Referring still to another embodiment as illustrated in Figure 5, the nodal message IG 70 once again contains a warning 72 denoting whether the restricted traffic state of the node is enabled or disabled. In this example, one or more TLV fields in the form of two restricted transit lists 74 and 76 are also part of the IG 70 nodal message. The restricted transit list 74, denoted as "LIST RT", is used in the case that notice 72 denotes that the restricted transit status of the announcement node is activated. The restricted transit list 76, denoted as "LIST NRT", is used in the event that the notice 72 denotes that the restricted transit state of the announcement node is deactivated. Regarding the respective examples of the nodal messages IG 50 and 60, the restricted transit lists 74 and 76 could denote exceptions for each of the restricted transit states of the announcement node in question or could denote definitions for each of the same, with the resulting analogous consequences in the event that a policy-based access establishment message identifies any of the flows, connections or traffic calls listed. Those persons skilled in this technique will understand that the structures rules and analogous data techniques could be used, if they are compared with those previously defined in relation to the modality of Figure 3, in order to implement the two lists of restricted traffic 74 and 76 and in order to compare a policy marked with them. Next, still with reference to an additional embodiment as illustrated in Figure 6, still another nodal message IG 80 is presented, wherein a warning 82, also identified as "RT PBR", denotes the restricted transit status of a node network that is differentiated in terms of flows, connections or traffic calls that are based on policy that is opposite to those not based on policy. In this example, if the warning 82 was activated, all flows, connections or traffic calls based on the policy will be prohibited from passing through the announcement node. On the other hand, where the warning 82 is deactivated, all flows, connections or traffic calls will be allowed to transit the node, without considering whether or not they are based on policy by nature. Those skilled in the art will appreciate that other data structures could be conceived for the announcement of the restricted transit restricted state of a network node in accordance with the present invention. Also, other rules and techniques of those described herein by way of example could be employed to compare a flagged policy with these announced data structures for the purpose of determining whether a call or connection will be allowed or forbidden to transit a network node. . Those skilled in the art will understand that various other modifications of detail could be made in the present invention, all within their spirit and scope. It is noted that in relation to this date the best method known by the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (10)

1. CLAIMS Having described the invention as above, the content of the following claims is claimed as property: 1. A method of transmitting a traffic flow in a communications network having at least one network node thereof for which the network traffic is prevented from traveling the same, selectively, characterized in that it comprises the steps of: selecting a specific category of network traffic that will prevent the network node from traveling; determine a path within the network for the transmission of traffic flow, where the network node is excluded that transits in the establishment of the access path where the traffic flow is identified with the specific traffic category of net. The method according to claim 1, further characterized in that it comprises the step of: communicating the specific category of network traffic by means of a network message propagated from the network node, and receiving the network message in a network entity where the step of determining the access path for the transmission of the traffic flow is carried out. 3. The method according to claim 2, characterized in that the specific traffic category of The network, which is prevented from traveling on the network node, is defined in relation to at least one parameter that is associated with the network traffic that is forbidden to transit the network node. 4. The method according to claim 2, characterized in that the specific category of network traffic, which is prevented from transiting the network node, is defined relative to at least one parameter that is associated with the network traffic that is allows the network node to transit. 5. The method according to claim 2, characterized in that the network node is provided with two operating states, a first state thereof in accordance with which the selected network traffic is prevented from traveling through the network node and a second state thereof according to which the selected network traffic is not prevented from traveling through the network node, a current state of the two operating states is communicated by means of the network message and where in the determination stage of the network the access path within the network for the transmission of the traffic flow, the network node is excluded in the establishment of the access path, where the traffic flow coincides with the specific category of network traffic and the current state It is the first state of it. 6. The method according to claim 2, characterized in that the opera communications network of According to the PN I protocol and the network message is a nodal message from the Information Group that has a length-value type field that defines the specific category of the network traffic. The method according to claim 6, characterized in that the specific category of the network traffic, which is prevented from traveling through the network node, is defined in relation to at least one parameter in the form of a Service Category label Network. The method according to claim 7, characterized in that the network node is provided as a restricted transit node and the type-length-value field defines the specific category of the network traffic by listing at least of a Network Service Category label that identifies traffic except for the restricted traffic operation of the network node. The method according to claim 7, characterized in that the network node is provided as a restricted transit node and the field of type-length-value defines the specific category of the network traffic by listing at least one tag of Network Service Category that identifies the traffic that defines the restricted transit operation of the network node. The method according to claim 7, characterized in that the network node is provided as a restricted transit node, and the type-length-value field defines the specific category of network traffic by listing at least one Network Service Category label that identifies traffic except for the restricted transit operation of the node Network when the restricted transit operation is activated and by listing at least one Network Service Category label that identifies the traffic excepted from the restricted traffic operation of the network node when the restricted transit operation is deactivated.