MPLS(Multi protocol Label Switching)

MPLS는 IETF에서 정의한 프로토콜로서 IP기반의 네트워크의 문제점을 극복하기 위한 것이며, 서비스 provideor의 core networks 또는 대기업 네트워크에서 주로 쓰인다.

MPLS의 핵심 기능은 IP네트워크 내부에 가상 경로(Virtual Circuits)를 구성하는 것이다. 이 가상 경로는 LSP(label switched paths)라 불린다. 이 LSP는 ATM이나 Frame relay networks상의 가상 경로와 유사하다.

MPLS구성도

 MPLS 동작개념도

MPLS 동작방식

 위 MPLS구성도에서 보여진 바와 같이, LSRs은 패킷들을 교체하는 핵심 장비이며, LERs은 외부 네트워크와 연결하고, 경로를 결정하고, 라벨을 부착/제거하는 종단 장비이다. 하나의 LSP는 end-to-end forwarding path를 구성하는 switch hops의 연결이다. LSP는 ingress LER에서 시작하여 하나 또는 여러 LSRs를 거쳐, egress LER에서 끝난다.

하나의 패킷이 MPLS 네트워크에 도착하면, ingress LER이 그 패킷을 제어하는데, 해당 패킷의 IP address를 보고, 경로를 결정하고, LSP할당 및 라벨을 부착한다. 그 패킷은 LSP로 forward되어지고, LER에 이를 때까지 LSR들을 거쳐서 이동한다. LER에 도착하면 레벨은 제거되고, 표준 IP Routing방식으로 보내진다.

기본(default) MPLS 라벨 할당과 라벨 forwarding 프로세스는 직접 연계될(attached)네트워크에 대한 정보를 알고 있는 개별 라벨 스위칭 장비와 함께 시작한다. OSPF나 BGP와 같은 라우팅 프로토콜이 라우팅 테이블을 구성하고, MPLS 장비는 그 때 라우팅 정보로부터 라벨 포워팅 테이블을 구성하고 이를 이웃 장비들에게 라벨정보를 배포한다. 그 테이블은 라벨이 어떻게 적용될 것인지의 정보를 제공하고, 하나의 라벨은 라우터가 결정한 포워딩 정보를 알려주는 짧은 표현형태이다.

< MPLS 라벨 할당 방식>

 위 그림을 한번 봐 볼까? 겁나 복잡해 보이지만, 실제로는 간단하다네.

 먼저 상단 우측의 LER2에는 2개의 네트워크 prefiexs가 있는데, Label9는 172.16, Label10은 129.10에 할당되어 있고

LER2는 이 라벨 할당 정보를 MPLS내부의 LSR들에 배포한다. 이 때, LER2는 '야 너네들, 나한테 172.16으로 가는 패킷 보낼 때는

라벨9붙이고, 129.10으로 보내는 것에는 라벨10붙여.잉?"라고 한다.

 MPLS내부의 LSR은 LER2와 LER3로부터 라벨할당정보를 받아서 내부에서 자신들의 라벨테이블을 만든다.

 <MPLS Label Forwarding>

실제 라벨 포워딩 방식을 한번 살펴보자고...

1.한 패킷이 ingress edge router LER1에 도착하면, LER1은 패킷의 IP주소를 검사하고 어떤 LSP를 사용하여야 할지 결졍한다. LER1의 라벨포워딩테이블은  prefix 172.18은 라벨3로 할당되어 있고 포트는 하나이므로,  포트0으로 해당 패킷을 라벨3로하여 보낸다.

2.LER1으로 보내진 패킷은 middle LSR에 도착하고, LSR은 label3를 자신의 라벨포워딩테이블에서 찾아본다. 거기에는 inlabel3은 172.18이며 이것은 outlabel9인 것과 해당 label이 포트0에 할당된 것을 확인하고 포트0,라벨9로 다시 보내는데. 이 때 해당 패킷의 라벨은 3에서 9로 교체한다.(Label Switching)

3.다음 hop으로 패킷이 도착하면, LER2는 라벨을 검사하고 이것이 라우팅테이블에서 라벨9가 포트0인것을 확인한다. LER2는 egress LER이므로, 더 이상의 라벨은 필요없으며, 기존의 라벨은 버려지고, 해당 패킷은 IP network 172.16으로 포워드된다.

라벨스위칭은 core LSR들에서 발생하고, ingress와 egress LER에서는 발생하지 않는다. swap operation은 incoming label을 조사하고, outgoing label과 output port를 결정하는 과정으로 구성되어 있다.

참고 RFC

• RFC 2702 (Requirements for Traffic Engineering Over MPLS, September 1999)
  
• RFC 3031 (Multiprotocol Label Switching Architecture, January 2001)
  
• RFC 3033 (Signaling for the Internet Protocol, January 2001)
  
• RFC 3036 (LDP Specification, January 2001)

참고자료 : http://www.linktionary.com/m/mpls.html 

이 글은 스프링노트에서 작성되었습니다.

 ARIES

-대다수 상용 DB에서 사용하는 복구 알고리즘

-a steal, no-force approach

 복구단계

1.Analysis : crash 시점의 buffer pool의 dirty pages와 active transaction 확인

2.Redo : 로그의 유효한 상태에서부터 시작하여 모든 action을 재실시하고 database 상태를 crash시점으로 복구

3.Undo : commit되지 않은 tx의 action은 undo하여 database에 commited된 tx의 action만 반영되도록 함

 ARIES 알고리즘의 원칙

1.Write-ahead logging

     DB객체에 대한 어떠한 변화도 먼저 로그에 기록, 로그에 있는 그 어떤 기록도 DB객체의 변화가 disk에 기록되기 전에 stable storage에 기록

2.Repeating history during redo

    crash 후 restart되었을 때 log의 모든 행위를 재실시하여 DB를 crash시점의 상태로 만든 후에 crash 시점에 active tx를 undo

3.Logging changes during undo

    tx를 undoing할 때 그 변화를 log에 기록. restart가 재실시될 때 동일한 action이 반복되지 않도록 하기 위함

이 글은 스프링노트에서 작성되었습니다.

 RUP라 불리던 Rational Unified Process.이제는 IBM으로 팔려갔으니 IBM RUP로 불림.(IBM Rational은 IBM의 자회사)

RUP Overview^#

정의 : 성공적인 반복-증분 SW 개발 프로세스 프레임워크

         a process framework for successful iterative-incremental software development

RUP의 Position

6가지원칙(A-F)^#

A : Adapt the process

B : Balance stakeholder priorities

C : Collaborate across teams

D : Demonstrate value iteratively

E : Elevate the level of abstraction

F : Focus continuously on quality

process framework란

다른 프로세스가 그 안에서 구성되고 개발될 수 있는 불완전한 지원 구조

an incomplete support structure in which another process can be organized and developed.

그러므로, 각 프로젝트에 맞게 tailoring을 해야함

RUP tailoring와 configuration 영향 요소^#

• 프로젝트 복잡도 Project complexity
•  조직 성숙도 Organizational maturity
• 조직 문화
• 규제 준수 및 지침 요구 Requlatory compliance and policy requirements
• 개발 유형
• 조직 규모

 Architectural Views^#

 RUP는 여러가지 아키텍처 뷰로 SW 아키텍처를 표현. 각 아키텍처 뷰는 개발프로세스안의 이해관계자들의 특별한 관심을 표시.

이해관계자에는 사용자, 설계자, 관리자, 유지보수자 등이 있다.

아키텍처 뷰의 주요 디자인 결정사항은 Perry & Wolf의 the software architecture in terms of how components connect to produce useful forms.1992에 의해 제공됨.

RUP에서 사용하는 전형적인 것은 4+1 view model

• use-case view : Requirements discipline
• logical view : Analysis and Design discipline
• Implementation view
•  Process view : Analysis and Design discipline
• Deploment view : Analysis and Design discipline

 Method and Process Definiton Language

 음 이건 이해가 잘 안되는구먼..

An Overview of the RUP^#

Architecture^#

겁나게 유명한 RUP hump 차트...

이건 phases, iterations, milestones, disciplines, 관계, lifecycle concept 정보로 구성.

Phases and Milestones^#

 RUP는 반복,점증적 SW개발 방법, 이것은 단계와 마일스톤으로 구성된 구조화된 생명주기안에서 발생하는 반복으로 생긴다.

phases : Inception, Elaboration, Constrution, Transition

 각 phase는 major milestion과 함께 종결된다.

 inception - Lifecycle Objective Milestone

elaboration - Lifecycle Architecture Milestion

Construction - Initial Operational Capabilitly Milestone

Transition - Product Release Milestone

Overview^#

 a discipline is a collection of related activities that are related to a major area of concern.

(discipline은 예전 버전에서는 workflow로 불렸다.)

현재 사용하는 phase를 기반으로 각 반복은 다른 discipline에 걸친 활동을 포함한다. 예를 들면, RUP에서는 가능한 빨리 실행가능한 개발을 하는 것이 주이지만, 비즈니스 문제와 기회를 이해한 제품을 생산하는 것도 중요하다. 따라서, hump 차트 biz modeling과 Requirements disciplines이 초기에 수행된다.

각 단계의 반복의 목표는 각자의 마일스톤을 성취하는 것과 맞물려 있다.

Inception Phase^#

objectives

• 프로젝트 범위와 경계, 조건 수립
•  시스템의 핵심 유즈 케이스 도출
• 하나의 후보 아키텍처를 전시 및 시범
• 프로젝트 전체적인 비용과 일정 추산
• Elaboration phase를위한 상세 추정 생산
• 잠재적 위험 예상
•  프로젝트 지원 환경을 준비

RUP는 Risk Driven. 큰 위험을 조기에 발견하고, 프로젝트가 더 진행되기 전에 그것의 위험을 완화하기 위한 노력을 기울임

Inception 단계는 최초의 제품을 릴리즈하므로 전단계중에서 가장 중요하다.

Lifecycle Objectives milestone이 이 단계를 종결. 이 때, 가장 중요한 결정은 프로젝트를 진행할 것인지 아니면 취소할 것이냐다.

Elaboration Phase^#

 이 단계에서의 가장 중요한 목표는 Construction phase에서의 설계 및 구현노력의 규모에 대한 안정적인 기준을 제공하기 위하여 시스템의 구조 베이스라인을 만드는 것이다. 하나 또는 여러개의 아키텍처 프로토타입이 만들어지는데, 이것은 실행가능한 것이다.

Objectives

•  아키텍처, 요구, 개별 계획을 안정화
• 프로젝트 비용,일정을 예상하여 결정하기 위하여 위험들을 충분히 완화
• 구조상의 주요 위험을 모두 인지
• 베이스라인된 아키텍처 수립
• 진화적 프로토타입 생산
• 선택적으로 throw-away 프로토타입을 특정 위험-설계트레이드요프, 컴포넌트재사용 등-을 완화하기 위해 생산
• 베이스라인된 아키텍처가 납득할만한 비용과 납득할만한 일정내에 시스템 요구사항을 지원할 수 있는 것을 데모
• 지원 환경 구축

The Lifecycle Architecture milestone이 Elaboration phase를 종결, 시스템의 관리된 구조 베이스라인을 수립하고, Construction phase동안 프로젝트 팀을 가용하게 함.

Lifecycle Architecture Milestone

The milestone for the Elaboration phase is establishment of the Lifecycle Architecture (LCA).
During the Elaboration phase, the Software Architect works especially closely with the Project
Manager and the System Analyst. This core team is usually smaller than the project team
necessary during the Construction phase. The set of requirements (for example, use-case
scenarios) drive the architectural prototype(s) and are used to validate important features and
requirements. Based on the findings and the progress of the requirements specification, the
Project Manager will be able to present to senior management at this point an improved
estimate and schedule. At the LCA milestone, high-priority risks should be removed and the
requirements more stable. The emphasis on work products during Elaboration includes the
following:

• Prototypes (executables that validate different architectural approaches)
• Risk List (revised)
• Development Process (the process as well as guidelines and templates have been
  refined, tailored, and streamlined for Construction)
• Development Infrastructure (tools and process automation support for Construction are
  in place)
• Software Architecture Document (created and updated with architectural findings)
  Demonstration that the baselined architecture will support the requirements
• Design Model (defined and architecturally important components assessed against
  scenarios)
• Data Model (created and entities, relationships and tables listed)
• Implementation Model (major components prototyped)
• Vision (revised based on the architectural findings)
• Software Development Plan (updated for Construction and Transition phases, including
  improved cost and schedule estimates)
• Iteration Plan (plan for the first iteration of Construction)
• Use-Case Model (the vast majority of use cases are specified)
• Supplementary Specifications (nonfunctional are documented)
• Test Suite (tests for the architectural scenarios are implemented)

Construction Phase^#

The main goals of the Construction phase are to clarify the remaining requirements and
complete the development of the system based on the baselined architecture. Construction
phase objectives can be briefly summarized as follows:

• To minimize development costs through optimization of resource utilization by avoiding
  unnecessary scrap and rework and by achieving a degree of parallelism in the work of
  development teams
• To achieve adequate quality as rapidly as is practical
• To achieve useful executable versions (alpha, beta, and so on) as rapidly as practical
• To complete the analysis, design, development, and testing of all required functionality
• To iteratively and incrementally develop a complete product that is ready to transition to
  its user community
• To decide if the software, the sites, and the users are ready for the deployment of the
  solution
• The Construction phase concludes with the Initial Operational Capability milestone, which
  determines whether the product is ready to be deployed into a beta-test environment.

Transition Phase^#

The overall goal of the Transition phase is to ensure that software is available for its users. It
can span several iterations and includes testing the product in preparation for release and
making minor adjustments based on user feedback. This feedback focuses primarily on finetuning
the product, configuration, installation, and usability issues. All the major structural issues
should have been worked out much earlier in the project lifecycle. Following are the primary
objectives of the Transition phase:

• To validate the new system against user expectations (by beta testing)
• To train the end users and maintainers
•  If applicable, to roll out the product to marketing, distribution, and sales teams
• To fine-tune the product by engaging in bug-fixing and creating performance and
  usability enhancements
• To conclude the assessment of the deployment baseline against the complete vision
  and the acceptance criteria for the product
• To achieve user self-supportability
• To achieve stakeholder concurrence that deployment baselines are complete and are
  consistent with the evaluation criteria of the vision
• The Product Release milestone conclud

RUP Phase Workflows^#

Each phase in RUP has a workflow, which describes the sequence in which activities from
across various disciplines can be performed to achieve the objectives of the respective phase
milestone. Chapter 14 explores in detail phase workflows and other process elements.

Discipline^#

This section covers the important aspects of disciplines in the RUP. However, before we get
into all the RUP details, let’s see what the term discipline means and how and why it is one of
the core components in the RUP.
Meaning of Discipline
According to the Merriam-Webster dictionary, the term discipline is defined as follows:

• From Latin disciplina teaching, learning, from discipulus
• To bring (a group) under control
• A field of study

• A rule or system of rules governing an activity

  
  As you can see, the term discipline has been historically used in relation to learning, teaching,
  controlling, and governing. Discipline is also defined as a controlled behavior expected to
  produce a specific improvement. Furthermore, it is defined as a pattern of behavior made up of
  a set of rules and methods. The next section demonstrates how most of these definitions of
  discipline apply to RUP in one form or the other.
  Briefly, in RUP, a discipline is defined as a categorization

 Discipline Workflow^#

RUP models the when as workflows, and each discipline in RUP has a workflow. Like other
workflows, a discipline’s workflow is a semi-ordered sequence of activities performed by specific
roles to achieve a particular goal. This semi-ordered nature of discipline workflows emphasizes
that they cannot present the nuances of scheduling “real work,” because they cannot depict the
optionality of activities or iterative nature of real projects. Yet, they still have value as a way for
us to understand the process by breaking it into smaller areas of concerns.
Keep in mind that the RUP framework, which these workflows are part of, constitutes guidance
on a rich set of software engineering principles. It is applicable to projects of different size and
complexity, as well as to different development environments and domains. This means that no
single project or organization will benefit from using all of RUP. Applying all of RUP will likely
result in an inefficient project environment, where teams will struggle to keep focused on the
important tasks and struggle to find the right set of information. Thus, as discussed earlier in this
chapter, it is recommended that RUP be tailored to provide an appropriate and customized
process for developing software. RUP tailoring and related tools are discussed in greater detail
in Part IV of this book.
It is important to understand that the sequence of activities in each of the workflows is based on
best practices. It should not, by any stretch of the imagination, be taken as a mandatory
sequence. As an important component of tailoring the RUP framework, these workflows should
be customized to suit project or organizational needs. This customization might require
redefining some of these sequences.

 Role^#

In RUP, a role is a definition of the behavior and responsibilities of an individual, or a set of
individuals working together as a team, within the context of a business organization. RUP uses
the concept of role to model the who of the software engineering process. This describes a role
played by an individual or team within the project. Each role may be realized by many
individuals or teams, and each individual or team may perform many different roles.

The Hump Chart—Putting Phases, Iterations, Milestones, and Disciplines Together^#

The reality is that a mini-waterfall project exists within each iteration of the RUP project.
Having discussed phases, iterations, milestones, disciplines, and other key concepts, let’s
revisit the famous RUP hump diagram shown in Figure 1-4 to put these together and discuss
the interrelationships in more detail.
The horizontal axis represents iterations and the progress of a RUP lifecycle. As discussed,
every RUP project is divided into four significant phases called Inception, Elaboration,
Construction, and Transition. We will discuss the four RUP phases in greater detail later in this
book. The dashed lines between the phases are called milestones, which mark checkpoints in
RUP. These milestones present a go/no-go decision by project management when artifacts
have reached a specified state. The word sign-off or freeze does not exist for RUP artifacts, but
artifacts need to reach specific states depending on the time in the RUP project lifecycle
reflecting the level of their maturity. For example, the first draft risk list is developed during the
Inception phase and is refined during the entire project lifecycle.
The vertical axis, called disciplines (called workflows in earlier versions of RUP), defines the
activities performed during an IT project. The RUP has nine disciplines. Six of them are directly
linked to software engineering activities and are also known as core disciplines. These are as
follows:

• Business Modeling
• Requirements
• Analysis and Design
• Implementation
• Test

• Deployment

  
  The other three are also called umbrella activities (also known as supporting disciplines),
  because they are concerned with the overall management and structure of a RUP project:

• Configuration and Change Management
• Project Management
• Environment

Iteration Maturity Levels^#

위 그림을 보면 네모 박스의 크기가 달라진다.

iteration 1에서는 중심이 Biz Modeling 2에서는 Analysis & Design, 3에서는 Test 로 focus가 이동한다

 Iteration Maturity Level 1—Incremental Mini-Waterfall^#

•  Lifecycle Objectives milestone— Scope and business case agreed
• Lifecycle Architecture milestone— Architecture baselined
• Initial Operational Capability milestone— Product sufficiently mature for use
• Product Release milestone— Product release

Iteration Maturity Level 2—Incremental Mini-Waterfall with Feedback Loops^#

Iteration Maturity Level 3—Optimizing Iterative and Incremental Development^#

 RUP 발전 단계^#

이 글은 스프링노트에서 작성되었습니다.